When the router is rebuilt, MenuRouterRebuildSubscriber forces all menu links to rebuilt. This happens within the overall route rebuild process. It's also the cause of one of the test failures on #2480811: Cache incoming path processing and route matching → .
Route rebuilding should definitely invalidate the menu links, but I'm not convinced we should do the actual rebuilding within the route rebuild.
The reasoning for this is that any submission that doesn't return a fully-themed HTML response (form POST submissions, REST, private files, image derivatives etc.) need the router to be rebuilt, but they don't need the menu links.
Therefore, if we allow the route rebuild to complete and release the lock faster, we could then start serving those kinds of responses after a route rebuild - 350ms faster with the standard install profile, but likely much more on real sites.
Add the ability to mark the menu links as needing rebuild, probably via a state entry. Set this during router rebuild, but then do the menu link rebuilding when that service is actually requested.
Decide whether this is desirable or not then implement if so.
None.
Possibly.
Closed: works as designed
9.5
It affects performance. It is often combined with the Needs profiling tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
We're still doing route rebuilds at the end of the request where they're non blocking, so closing this one out.
📌 Add a cache prewarm API and use it to distribute cache rebuids after cache clears / during stampedes Needs work is more comprehensive and applies a similar decoupling concept for a lot of different rebuilds though.