Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We are currently having issues with the cron-hook of storage_api.
If i run the SQL from _storage_check_files
manually i get 379.447 entries that cron should go through. This number never seems to drop, only increase, and the cron-run never succeeds.
I think i have located the source of the problem in storage.inc
line 712:
// If the storage has a single instance in a container that is not
// propagating, then we are done.
if ($this->file_id) {
$query = db_select('storage_instance');
$query->join('storage_class_container', NULL, 'storage_instance.container_id = storage_class_container.container_id');
$query->join('storage_selector', NULL, 'storage_class_container.class_id = storage_selector.class_id');
$count = $query->condition('storage_instance.file_id', $this->file_id)
->condition('storage_class_container.propagate', 0)
->condition('storage_selector.selector_id', $this->selector_id)
->countQuery()
->execute()
->fetchField();
if ($count) {
return;
}
If the last condition is true, the file is still marked as one that should be processed by cron, and will probably return in the same result the next time.
This does not seem right. Maybe it should mark this storage as idle (STORAGE_STATUS_IDLE) as it is on line 779:
if ($this->selector_id) {
$this->initial_container_id = NULL;
$this->status = STORAGE_STATUS_IDLE;
$this->update();
}
Comment | File | Size | Author |
---|---|---|---|
#2 | storage_entries_not-2597119-2.patch | 290 bytes | mian3010 |
Comments
Comment #2
mian3010 CreditAttribution: mian3010 commentedAttached proposed patch.
Comment #3
Perignon CreditAttribution: Perignon commentedThanks for the patch. Looking it over now.
Comment #4
Perignon CreditAttribution: Perignon commentedDid you get this tested locally?
Comment #5
Perignon CreditAttribution: Perignon commentedKick testbot off.
Comment #6
mian3010 CreditAttribution: mian3010 commentedI have tested it locally, and it seems to work.
I can confirm that the number of unprocessed items (1.358.171 locally) is falling quickly when running cron. That was not the case before the patch.
Comment #7
mian3010 CreditAttribution: mian3010 commentedI can confirm that the number of entries that cron should process has reached 0 both locally and on our pre-production environment.
Comment #8
Perignon CreditAttribution: Perignon commentedAwesome!
Comment #10
Perignon CreditAttribution: Perignon commentedJust pushed the commit. There was also another commit just updated today that I got in from Github.
Comment #11
Perignon CreditAttribution: Perignon commented