Patternkit blocks cause unintentional page cache invalidations on edit and save

It got rather complex trying to separate out the different types of cache tags and what their desired behavior should be, but this is what I settled on (obviously open to feedback).

Types of cache tags

• Block data entities (contains pattern configuration values): patternkit_block:123
• Pattern data entities (contains versions of the pattern schema, template, etc.): patternkit_pattern:456
  • These target the specific entity ID of the pattern entity, and I've made efforts to move everything toward only one pattern entity per pattern definition moving forward, but I think there's some historical behavior that'll have multiple entities for the same pattern in the database for existing sites. This should get resolved over time with the new work allowing a clean-up in the future.
• Pattern type (the pattern identifier itself that should cover anywhere the pattern is used even if multiple entities of it exist in the database): pattern:@patternkit/example/src/example
  • I kept these in to help with allowing invalidations targeting anywhere the assets (js/css) for a given pattern may have been changed and need to be updated.

Intended behavior

With the different types of cache tags and their intentions clarified, we can tackle the invalidation behavior a bit more clearly.

• Whenever a patternkit block is created or updated, the cache tag for that specific entity ID (patternkit_block:123) should be invalidated, but only once the layout itself is actually saved. Unless a block is marked as reusable and placed on multiple pages, this shouldn't cause invalidations anywhere else.
• Whenever a new pattern is used for the first time, an entity for that pattern has to be created when the block is first saved. This shouldn't trigger either until the layout is saved, but it will trigger invalidations for both the pattern entity ID (patternkit_pattern:456) and the pattern name (pattern:@patternkit/example/src/example), neither of which should have records to invalidate if this is the first usage.
• After a pattern has already been used, the user should never be prompted to update it and the tags for either the pattern entity ID or the pattern name should not be invalidated as long as the files loaded from the filesystem for it never change causing the hash to differ. Assuming that's the case, updates to existing blocks and even the creation of new blocks using this pattern should never cause invalidation of either the pattern entity ID or pattern name.
• If the files for a pattern are changed, an available update should be detected and a user is prompted to update the pattern on all block edit forms using that pattern. Clicking the update button should save and create a new revision for that pattern entity, but it should not invalidate caches for either the pattern ID or pattern name cache tags yet. Once the layout is saved, cache tags for the patternkit block, the pattern entity, and pattern name should all be invalidated. This will cause invalidations to hit other nodes where that same pattern may be used even if they aren't targeting the new revision yet, but without changing all of the pattern entity cache tags to target revision ID instead of entity ID there's not much way around it.

TL;DR

• Block entity ID tags should be invalidated when a layout is saved after creating or updating a new patternkit block
• Pattern entity ID tags and pattern name tags should be invalidated when a layout is saved after first using a new pattern or updating the pattern to use changed files on the filesystem

I have tested the patch and the patternkit_block:BLOCK-ID cache tags are now getting invalidated only when a new node revision is created. This is how Drupal core is operating as well with custom-blocks. Things are looking good.

+1 on getting this merged in.

Retested the changes and it is working as expected now.

Steps:

1) Install the modules: Patternkit, Patternkit Example, Layout Builder
2) Enable cache header output by enabling http.response.debug_cacheability_headers as true in core.services.yml file
3) Enable Layout Builder with page-specific overrides on a content type
4) Create and save a new page (Page 1)
5) Edit the layout for this page and place a new "[Patternkit] Example" block
6) Save the layout and view the page
7) View the cache headers for page 1
Results : Expect to see a cache miss

8) In the original window, create and save a new page (Page 2)
9) Edit the layout for this page and place a new "[Patternkit] Example" block, saving the layout
10) View the cache headers for Page 2:
Results : Expect to see a cache miss

Block Editing

11) Edit the layout for Page 1
12) Edit the example block already on the page
13) Change some field content and submit the block form (Do not save the layout yet)
Results : At this point, the changed content should be visible on the layout preview screen.
view the published version of Page 1:
Results: Expect to see the unedited block content and a cache hit for the page

14) In the original tab, save the updated block layout.
Results :

Expect to see the changed content on the published view of Page 1
Expect to see a cache miss for the page.
15) View the published view of Page 2:
Results: Expect to see a cache hit for the page

Attaching Screenshots.

Merging for inclusion in the Beta 7 release.

Automatically closed - issue fixed for 2 weeks with no activity.