- Issue created by @berdir
- 🇨🇭Switzerland berdir Switzerland
I tried adding another drupalGet(), but that does just hit the page cache obviously. I might need to invalidate, request and then invalidate again, not sure.
I debugged the request a bit. The caches aren't invalidated by a tag, they don't exist. Maybe something weird about the way the performance tests empty all cache bins?
The first query is due to the dynamic page cache cache context (is frontpage), which seems a bit pointless given that this already depends on the route. that reminds me about a very old issue about being able to merge and drop certain cache contexts that aren't direct children, the examples back then were user roles vs permissions and locale cache context when a site doesn't allow to customize it, but this also seems like a candidate.
I think it makes sense to put this on hold until it's clearer what we want to do with 🐛 RoutePreloader loads a lot of routes Active
- 🇨🇭Switzerland berdir Switzerland
Rebased, just creating two nodes now with a get inbetween, then the route cache is filled.
- 🇺🇸United States smustgrave
Terrible at reviewing these but know you know what you're talking about. There are a few cache tickets in review that I don't know will help cover those too but would like to find out.
- 🇨🇭Switzerland berdir Switzerland
One option to change this is to move it to an authenticated user and save the node through the UI. That should both avoid this weirdness and allow to a performance test on saving a node, which would be interesting to track improvements around that.
The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.