- Issue created by @NicholasS
- 🇩🇪Germany gbyte Berlin
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.
- 🇦🇺Australia dpi Perth, Australia
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.
- 🇩🇪Germany gbyte Berlin
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.
- 🇺🇸United States NicholasS
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 use ~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
- 🇺🇸United States NicholasS
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.
- 🇦🇺Australia dpi Perth, Australia
Once you clear the cache its solved.
Its only disruptive for the deployments running after the upgrade.
- Assigned to dpi
- 🇦🇺Australia dpi Perth, Australia
Linking cause 📌 simple_sitemap.queue_stashed_results should be in keyvalue instead of state Fixed
- Issue was unassigned.
- Status changed to Needs review
7 months ago 7:52am 4 May 2024 - 🇦🇺Australia dpi Perth, Australia
- last update
7 months ago 32 pass - Status changed to Fixed
3 months ago 8:23am 16 August 2024 - 🇫🇮Finland vermario
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?
- 🇫🇮Finland vermario
oh, sorry I missed it :-)
(strangely the problem still happened in my deployment even with that piece of code...)
Automatically closed - issue fixed for 2 weeks with no activity.