The issue is not only when a user goes back to a previous page. On our site it happens like this:
A user on foo.com/bar logs into the site and is redirected to www.foo.com/bar?check_logged_in=1
Now they copy their URL to share with someone else.
Error is displayed to anonymous user.
This even happens to me while working on the site- I log in and copy the URL, then open an incognito window to compare the authenticated page to anonymous page- error displays on anonymous page.
We could just remove the error message considering that it is seems more likely to get the message in error than to get it in a useful way. If your browser doesn't accept cookies, you will probably figure out sooner or later that you really can't log into anything- not sure we need to take responsibility for explaining that one.
Confirmed that we are running this patch in production and our Cloudflare cache hit rate increased significantly
Thanks, merged, please roll a new tag and release
Merged and new alpha release rolled. Thanks!
Thanks @weekbeforenext. We have been dealing with a similar bug, possibly the same thing.
We have only been able to reproduce it on our live site where we can't clear the cache to confirm it. It did sound like it was possible that your observation that disabling diff was unrelated and just that disabling anything cleared the cache.
For us the issue is intermittent, consistent with a race condition. Sometimes an editor saves a node as published revision, but then is redirected to the 'latest' tab as if there were a draft revision. The 'latest' tab then gives a 403 as there is no draft revision, and the revisions tab shows that the latest published revision is not the 'current' revision as you showed. The changes made are not published, and when the editor tries to edit the page again they can get the error that 'the content has been edited by another user' as well.
The timing of this bug started happening for us at the same time that we were adding a bunch of additional logic on node saves to customize which cache tags were clearing depending on which fields were modified. So perhaps adding in more logic or more cache tags to invalidate led to to this race condition becoming more likely to fail.
We are not able to reproduce the bug outside prod, but we'll follow your advice and try that patch, as a race condition related to cache tags sounds about right.
Thanks guys
I don't personally find hook_help to be useful, but whatever makes you happy.
Thanks @dineshkumarbollu
Some of that was useful. A lot of the comments I had to rewrite.