Problem/Motivation

After updating to 4.1.9 we had to revert back because we had an error during deployment. I am not sure what caused it but figured I should report it here. We reverted back to 4.1.8 we have a fairly typical setup, the error occurred a few mins after the code was deployed likely after cron ran? But I'm not sure.

Steps to reproduce

Update from 4.1.8 to 4.1.9 then I think wait for cron to run and I get the following error. But not 100% sure yet how to reproduce the error. 

TypeError: Drupal\simple_sitemap\Queue\QueueWorker::__construct(): Argument #2 ($state) must be of type Drupal\Core\State\StateInterface, Drupal\Core\KeyValueStore\KeyValueFactory given, called in /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\simple_sitemap\Queue\QueueWorker->__construct() (line 153 of modules/contrib/simple_sitemap/src/Queue/QueueWorker.php).
Drupal\Component\DependencyInjection\Container->createService(Array, 'simple_sitemap.queue_worker') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('simple_sitemap.queue_worker', 1) (Line: 440)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 237)
Drupal\Component\DependencyInjection\Container->createService(Array, 'simple_sitemap.generator') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('simple_sitemap.generator', 1) (Line: 440)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 237)
Drupal\Component\DependencyInjection\Container->createService(Array, 'simple_sitemap.form_helper') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('simple_sitemap.form_helper') (Line: 197)
Drupal::service('simple_sitemap.form_helper') (Line: 43)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#2 sitemap.jpg160.97 KBnicholass

Issue fork simple_sitemap-3444946

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

NicholasS created an issue. See original summary.

nicholass’s picture

nicholass
Primary language English
Location FL
commented
Issue summary: View changes
StatusFileSize
new sitemap.jpg160.97 KB
gbyte’s picture

gbyte
Location Berlin
commented
Category: Bug report » Support request
Priority: Major » Normal

I may be wrong but your deployment might have been at fault - state was indeed replaced by the key/value store and the error you are getting may be due to a partially old code base or some cache. Please retry the update, run `drush updb -y && drush cr` afterwards and let me know if the modules works.

dpi’s picture

dpi
Location Perth, Australia
commented
Category: Support request » Bug report

If you change services, you need to reset the container.

The typical pattern is by implementing an empty postupdate hook. For example `user_post_update_sort_permissions` / `layout_builder_operation_link_post_update_remove_destination_form_link`.

I've hit this on a handful of projects so far, its annoying that it breaks CI requiring a manual CR beforehand. Especially if you dont have another module implementing an update that happens to do it for you.

A postupdate should be implemented.

gbyte’s picture

gbyte
Location Berlin
commented
Version: 4.1.9 » 4.x-dev

A postupdate should be implemented.

Yeah maybe that's what we should be doing - feel free to create an MR. Alternatively adjust your deployment so it cleans the cache which has been the recommended approach since I can remember. I'm surprised your site doesn't break after every update.

Also please open up bug reports against the dev version of the module and only support requests against the stable version.

nicholass’s picture

nicholass
Primary language English
Location FL
commented

Just as follow up our deployment CI is pretty typical, its an Acquia Cloud Next hook as follows and it was clearing cache after deployment. Again too this white screen of death only happened to us ~5min after deployment when our Cypress Testing was about half way through testing, and we have about 509 cypress tests that test various routes of the CMS and features. 

drush cr
drush updb -y
drush cim -y
drush cr
drush sset environment_indicator.current_release $deployed_tag

Thats what I found really odd is the delay until the error appeared which made me think it could be cron half way through the automated testing.

nicholass’s picture

nicholass
Primary language English
Location FL
commented

Update: So today I tried another migration again and its seemed to not be a problem, so could have just been a deployment hiccup? I guess well see if it happens to others or not to see if its an issue, and I guess worst case it can be solved with a cache clear I assume.

dpi’s picture

dpi
Location Perth, Australia
commented

Once you clear the cache its solved.

Its only disruptive for the deployments running after the upgrade.

dpi’s picture

dpi
Location Perth, Australia
commented
Assigned: Unassigned » dpi
Related issues: +#3436960: simple_sitemap.queue_stashed_results should be in keyvalue instead of state

Linking cause #3436960: simple_sitemap.queue_stashed_results should be in keyvalue instead of state

dpi’s picture

dpi
Location Perth, Australia
commented
Assigned: dpi » Unassigned
Status: Active » Needs review

MR @ https://git.drupalcode.org/project/simple_sitemap/-/merge_requests/93

dpi opened merge request !93

  • gbyte committed 47562635 on 4.x 
    Issue #3444946 by dpi, NicholasS, gbyte: QueueWorker Error after...
gbyte’s picture

gbyte
Location Berlin
commented
Status: Needs review » Fixed

Thanks.

vermario’s picture

vermario commented

I have seen this same issue after deployment with the latest version of the module.

Looking at the code in the commit above, it seems that there's only an empty function, is that intentional? Or did we need something like 

  drupal_flush_all_caches();

in there to actually clear the cache?

dpi’s picture

dpi
Location Perth, Australia
commented

See 4

vermario’s picture

vermario commented

oh, sorry I missed it :-)

(strangely the problem still happened in my deployment even with that piece of code...)

dpi closed merge request !93

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.