- Issue created by @mortona2k
- π¦πΊAustralia pameeela
Thanks, agree this is confusing! Moving over to core though because this doesn't have anything to do with Drupal CMS really.
- π¦πΊAustralia pameeela
Hmm, I can't seem to reproduce this in Drupal CMS or vanilla core?
- πΊπΈUnited States mortona2k Seattle
It happens when Browser and proxy cache maximum age is on in Development > Performance.
With caching disabled, there is no issue.
I can toggle it on and off to repro currently.
- π¦πΊAustralia pameeela
I've got it enabled too in the screencast, set to the default of 15 minutes. (The proxy cache settings shouldn't have any effect on the caching of things in the admin UI.)
- π¨π¦Canada m4olivei Grimsby, ON
I can reproduce on the latest 11.x when I install Drupal's standard profile and enable Navigation module.
Updating issue description.
- π¬π§United Kingdom catch
I was able to reproduce this locally, didn't step through or anything, this is from reading code and memory of what happens.
I think it's a race condition:
1. Adding a content type creates a new menu item (via navigation_menu_links_discovered_alter()).
2. On the post request when the form is submitted, a router and menu link rebuild is triggered - but the actual rebuild happens in a post response subscriber by design.
3. When the next page is loaded, the router and menu link rebuild hasn't finished yet, so the stale navigation menu structure is shown
4. By the time you refresh, the menu link rebuild has finished, caches are flushed, fresh version of the navigation toolbar shows up.This also might explain why @pameela couldn't initially reproduce it, because if the menu rebuild happens to finish before the navigation bar gets rendered, then it's all fine, it's only a problem if it finishes after.
The only way to completely prevent this would be for us to artificially delay the rendering of the navigation menu trees when we know a menu rebuild is in progress.
It would mean acquiring a lock when setRebuildNeeded() is called and removing the lock only after route rebuild subscribers including menu links are rebuilt.
I think the only reason that menu links are rebuilt at all is due to field_ui_entity_bundle_create() - it may be that the menu is permanently stale in navigation if field_ui module is uninstalled. So it might need its own hook_entity_bundle_create() hook implementation anyway.
Navigation could set a look in hook_entity_bundle_create().
It could release that lock in route rebuild subscriber that runs after the menu link rebuild subscriber, or in its existing navigation_menu_links_discovered_alter() implementation maybe.
When rendering navigation menus blocks, check if the lock is in place, and then delay rendering until it's not via lock wait.
But that should only happen when caches are cold IMO, so it probably also needs to invalidate a cache tag in hook_entity_bundle_create() so that navigation menu render caches are empty between the rebuild being triggered and it being completed, then they'll hit the cold cache path and check the lock.