Project

General

Profile

Actions

Bug #102302

closed

sys_file_processed entries overwritten with null values

Added by Mordamir 8 months ago. Updated 7 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2023-11-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
8.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

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?

Actions #1

Updated by Mordamir 8 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.

Actions #2

Updated by Mordamir 7 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.

Actions #3

Updated by Georg Ringer 7 months ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF