Form Actions Stay Cached and Disabled After Breaking Lock in Gin Admin Theme

I have tested the MR using Gin 5.x and can confirm is working.

RTBC+1

I can't reproduce this with gin and 11.2.x or 11.x on the latest content lock.

Here's what I've done:
1. Install Drupal standard
2. Enable content lock and configure it for nodes
3. Install gin and set it as the admin theme
4. (optionally) configure gin to "Enable sticky action buttons" as I thought this might be the cause.
5. Create another admin user.
6. Create a node and then edit it.
7. In another private browser window log in as the other admin and go to edit the node I created
8. Click on the break lock link
9. Click on the confirm break lock link
10. Links are active when I return to the node for editting.

What step am I missing?

I'd like to write a failing test for this as gin is moving to core...

Not sure why this was Needs Work (no comment or issue summary unfinished). We have tested this out and it solves the described problem. Invalidating the cache tags like this for the specific entity seems to be a good idea and is a safe easy win.

@scott_euser because we have no test coverage - and I cannot reproduce locally? See #8 I've followed the steps to reproduce on a vanilla drupal install with the latest gin and content_lock and it does not occur.

Aha sorry ill try to give steps, need to unpick a bit back to standard install

Okay I know how to reproduce now and I think I understand why.

So exactly your steps in #8 BUT also have scheduled_transitions (for example) enabled.

That module adds a url.path to cache contexts (in addition to existing tags) in ScheduledTransitionsLocalTask::getCacheContexts. That that gets applied to Navigation module PageActions::build().

I am not sure if other modules cause that problem too by adding a block that is based on a URL, but when one does it causes this problem. I am adding a test doing the same just by adding a block in a test module.

What I am really not sure of though is

1. if this is a sign of Navigation not having the correct cache tags or cache tag invalidation in the first place
2. or if all modules like Scheduled Transitions should avoid url.path
3. or if fixing here is the right thing to just avoid that altogether

Okay test coverage passes and test only fails

So I'm not a fan of this change because anything displaying lock information is uncacheable - we have several code paths which are setting max age to 0 because of this. I wonder does https://www.drupal.org/project/content_lock/issues/2919019 fix this. Let's see if I can reproduce the issue locally with the new info.

So I've tried to reproduce by installing scheduled transitions and content lock and I cannot reproduce the issue on 3.0.x. I've tried with the navigation or the toolbar module installed.

Here's my steps:

• Install standard 11.x, content_lock 3.0.x, scheduled transitions and gin (via composer require)
• Create a content type and enable it in content moderation, content lock and scheduled transitions
• Edit it with one admin user
• Edit it with another admin user in a different browser and break the lock

What am I doing wrong. I'm not disabling the render cache.

Okay I see why this is harder to reproduce sorry! I hadn't updated Gin in my report in #12 which made this innaccurate, and had not noted that the users I used were two different roles. This fix in Gin set max-age 0 for a different issue: https://git.drupalcode.org/project/gin/-/work_items/3585951

Before that, using 2 admin users wouldn't work because the cache context is user.permissions in top bar here:
https://git.drupalcode.org/project/drupal/-/blob/main/core/modules/navig...
So you would need the two users to have 2 different roles so their permissions hash is different.

The max-age: 0 workaround that Gin added probably fixes the symptom for most cases. I suppose its possible some other contrib caches something else on the screen based on the entity cache tags e.g. some sort of block, so it could be useful anyways (and that is what the test covers). Or perhaps some contrib adds something else to the top bar that is outside of Gin's cache? So not sure if this should be 'Closed (outdated)' or could be added anyways to avoid a future issue.

Given #16 going to close as outdated. I think if you add content lock information to a block you're going to need to handle the cache implications in the code that does that. I.e. set the cache max age to 0 because you can lock just by visiting the edit of node. Hence this info is basically uncacheable.

Sounds good! For anyone hitting this upgrade to Gin 5.0.13 or greater.