Cache not invalidated after bulk alias generation or deletion

Thanks for reporting this. We already have an issue for this at #2480077: Using the URL alias UI to change aliases doesn't do necessary invalidations: path aliases don't have cache tags.

(Kind of crossposting, keeping this open, as I think a fix/workaround in pathauto is a lot more likely/easier than fixing the core issue)

That's certainly an interesting one. There are core issues, since we really just us an API but I believe it will be hard if not impossible to fully address this in core. As aliases and system paths are everywhere and we'd need dozens if not hundreds of cache tags on some pages.

I think we can fix this by explicitly clearing the cache tags (Cache::invalidateTags(getCacheTagsToInvalidate())) of an entity when we generate an alias, probably only when doing so through bulk methods that don't involve saving the node.

Shouldn't be too hard to start working on that, we should also make sure we have a test for this. We can possibly extend our existing tests by going to admin/content or so between the steps of the e.g. the bulk delete + generate tests and asserting the results there.

I think a fix/workaround in pathauto is a lot more likely/easier than fixing the core issue

Great point!

Plan sounds good too. But AFAIR you will also have to implement the "when rendering" part of #2480077-12: Using the URL alias UI to change aliases doesn't do necessary invalidations: path aliases don't have cache tags.

Not sure if this is on topic and if it's a core or a pathauto issue but when performing migrations with pathauto enabled, performance degrades horribly.
Take a migration of 50 000 nodes which takes less than 2h to finish. It takes twice as long (4h+) with pathauto enabled.

As performance degrades gradually it might indicate a schema/index issue or the cache invalidation overhead becoming larger, I'll have to dig into the issue deeper to find the bottleneck. I already noted a similar degrading performance with migration+pathauto in Drupal 7.

So to make it on topic: when implementing cache invalidations, please keep migrations in mind.

See #2765729: PathautoPattern->applies() exponentially slows down operations with large numbers of nodes on that topic.

Summary

Bulk alias operations (generate, update, delete) did not invalidate render caches, causing pages to continue showing stale aliases until caches expired naturally.

Problem

When aliases were created, updated or deleted in bulk (via the admin UI or Drush), Drupal's render cache was not invalidated. This meant anonymous visitors (and any page behind page_cache / dynamic_page_cache) would still see the old aliases — or broken links — until the cache was manually cleared or expired on its own.

Changes

• EntityAliasTypeBase.php: In batchDelete(), after deleting aliases the entity cache tags (node:123, etc.) are now invalidated for every affected entity. In bulkUpdate(), cache tags from entities whose aliases were actually changed are collected and invalidated at the end of the batch chunk.
• AliasStorageHelper.php: The deleteAll() method (fast path that truncates tables) now invalidates the rendered cache tag, since there are no individual entity IDs to target when wiping everything.
• PathautoAdminDelete.php: The per-type fast delete path (no custom alias preservation) now also invalidates the rendered cache tag after deleting aliases by source prefix.
• PathautoCacheInvalidationTest.php (new): Functional test with page_cache and dynamic_page_cache enabled. Covers four scenarios — bulk update, batch delete (keep custom), delete all (fast path), and per-type delete (fast path) — each priming the page cache, running the operation, then asserting the next anonymous visit is a cache MISS.

A few minor comments. Fine to merge after this I think.

This only handle bulk generation and deletions, I'd suggest we adjust the issue title to better explain what it does.

> The cache is updated by other means like entering the URL alias by the node/edit form (handled by the core path module) so I consider the evidence a bug in pathauto.

FWIW, this statement from the original issue isn't correct. the path module doesn't do that. Saving the node is what invalidates the node and therefore anything cached with that using that. If you'd use the path UI to manually create an alias that doesn't invalidate anything. But that's not our concern, that's what the core issue is about which will likely never be resolved, as the cost is far bigger than the possible gains. In practice, most sites use redirect module which handles outdated/missing aliases through redirects, so this is all pretty minor.

Similarly, there are going to be cases that use the link without the node cache tag, I don't think linkit or the new core feature for that adds that for example. So those would not be invalidated. But again, not our concern and not a big issue.