Bug #102302
closed
sys_file_processed entries overwritten with null values
0%
Description
After Upgrading typo3 to version 11.5 we got a problem with processed images. The processed images was all cleared after the update.
But after some time we found many database entries in sys_file_processedfile with identifier set to empty and name to null. After reading some other issues this is the normalbehaviour for images which dont need processing. But in our case its a little bit different: The images are first processed normally with correct entries to sys_file_processedfile and later overwriten with the empty values.
example sys_file_processedfile:
uid tstamp crdate storage original identifier name configuration configurationsha1 originalfilesha1 task_type checksum width height processing_url
after first processing: 711344 1698676626 1698676626 1 10113 /_processed_/b/8/csm_2019-07-16_Salbei_1_1c6cce4b4... csm_2019-07-16_Salbei_1_1c6cce4b48.jpg [BLOB - 174 B] e68b0574e8909d6bdf9714bb2b6d79f791a1494e 89d18842cc172696606416e426948cae08bf130d Image.CropScaleMask 1c6cce4b48 1080 1920 NULL
after some time: 711344 1698682465 1618402081 1 10113 NULL [BLOB - 174 B] e68b0574e8909d6bdf9714bb2b6d79f791a1494e 89d18842cc172696606416e426948cae08bf130d Image.CropScaleMask 1c6cce4b48 1080 1920
Most values are the same, only tstamp, crdate, identifier, name and processing_url are changed. Looking up the access log at the tstamp-value i did not find suspect access. The timestamp also does not appear the be the time the zeroing happens, because this is 2 days older then change happens to the page with the image.
The question for me is how its possible that an already processed image (db entry) gets overwritten? The processed image itself does not get deleted, but will not be used anymore, because the db says there is no processed image.
And second, how can i find the cause?
Updated by Mordamir 6 months ago
It looks like the main trigger in our case is something the indexed search indexer is doing. Thats why i never found an entry to the webservers access log at the timestamp of the wrong database entries. The indexer is configured the access the pages directly, so it may be because of incomplete TSFE initialization inside the indexer, but this is pure speculation.
As long as i keep the indexer off, the problem is solved.
Updated by Mordamir 5 months ago
Problem really solved.
The root cause was an old staging version which used the same database, but not the same files. So with every request to the staging site, typo3 marked the (in the staging version) not available files as not available, which is correct for the staging version, but not for the live version.
Lessons learned: never use the same database for different typo3 installations.
Updated by