Updates to content type names are not reflected in the menu item labels

Moving to NR. The PHPStan error seems unrelated to the MR.

You only need to rebase the MR. That PHPStan problem was fixed in main earlier. This must have been forked during the brief time this morning when the baseline was wrong.

Thank you for the heads-up!
Pipeline is Green now.

Thank you for the recording. It was very helpful.

Back to NR.

Thank you for the in depth testing.

Found out that the issue was related to how routes are being rebuilt after saving the content types, that force a route rebuild happening at the terminate phase, once the response is sent.

Ended up forcing to rebuild the dynamic menu links as part of the entity type insert/update/delete to ensure that links are properly generated in the next page load.

Didn't test, but forcing a rebuild is likely going to significantly impact installations of large install profiles/recipes with many node/media types.

Good point.
I did not considered the possible implications during installation phase.
Do you have a in mind a possible alternative?
What I experienced locally was that even if the rebuild is triggered during the bundle creation, it happens during the terminate phase of the request. And locally, maybe not in real scenarios, seemed that the navigation was built at a point where the custom content links built on the fly were not ready yet. Forcing to to ensure that rebuild happens before the response is sent helped to address the issue. Initially tried invalidating the content menu cache tags, but it did not work.

I agree that's not perfect, but if they correctly rebuild at some point, that might be acceptable? If it's an issue for tests, we have a feature in place that allow a test to wait for that, see WaitTerminateTestTrait. It's a tradeoff with the delayed rebuild/terminate event in general. If we think it's a UX problem for cases like this, we could possibly build in a feature that allows certain things to flag that we want to hold back the response and run terminate before that? Not sure.

I'm wondering if a long-term solution would be to build this create menu on the fly instead of indirectly through menu links. I understand that menu links allow to customize it, but I'm not sure if a mix of manual links and generated ones play so well together anyway. And it was probably the most convenient option. Then we could add a cache tag on entity_bundles or so and this would automatically invalidate and rebuild as necessary.

Something like \Drupal\Core\Entity\Controller\EntityController::addPage().

I'm also not sure how well the current feature scales, what about sites that have 20, 30+ node types, how does the UI look then? I think it's generally less common than it used to be in D7, but possibly that's also influenced how we build our projects. A fully dynamic block would allow more flexible solutions for that, like grouping or expand/collapse features.

Worst case scenario, the data would be synced after a cache clear.
And the creation/modification/deletion of bundles is not an operation that happens very often once the site is more or less stable.
Could we live with this for now?
This issue might address the update related issues and leave the add/delete, which affect to routes, for a later discussion.

Thanks for that reference, I wasn't following that and the linked #3573730: Improve usability of 'Create' menu in navigation. Following both now. I did see that the very old #2377543: Add "Add" item to toolbar. was also mentioned there, sounds like we're going full circle on that now.

Not surprised that the order isn't in sync, but I feel like trying to solve that with the current menu link approach is pretty futile, especially when you add manually created links to the mix then it is pretty impossible to manage.

At this point I'm not entirely sure if we even want to do these imperfect fixes this if we're really going to make major changes to that section and possibly replace this code completely. Maybe we should figure out first how the preferred solution would look like and how we'd build that? Some ideas sound like we'd essentially reintroduce shortcuts module just as we're deprecating it (letting users mark which things they want to see there).

Taking a break and decide the long term requirements sounds a sensible a this point.

There are different issues trying to make improvements to that part, and some coordination might be necessary.

Is the current implementation highly opinionated and maybe we need something simpler? Or maybe just move the current menu to the standard profile and let site admins to customize them manually after installation? Or a configurable block, as mentioned in a previous comment where a set of bundles can be chosen?