Taking over a locked post does not always load the most recent revision

[johnbillion]

Steps to reproduce:

1. Open up a post for editing, and make some changes to it. Do not save the changes.
2. Open up the same post for editing using a different user account (in a different browser[1]) and click the 'Take over' button when you get the post lock modal.
3. Note that the post that loads is not the most recent autosave of the post, but equally importantly you are not shown the message stating this.
4. Reload the editing screen and you'll be presented with the "There is an autosave of this post that is more recent than the version below." message.

Related: #23697

---

[1] The simplest way to do this is to use an Incognito browser window (and ​User Switching) so you can be logged in as two accounts simultaneously.

[azaozz]

Can reproduce when autosave has not run between steps 1 and 2 above. As it runs on one minute interval, there can be some changes that haven't been saved yet when user B takes over post editing unexpectedly from user A. The last changes from user A are autosaved when the "Post taken over" dialog shows, i.e. after user B has already loaded the screen. Any ideas/suggestions on how to improve this are welcome.

[azaozz]

The gist here is "user B takes over post editing unexpectedly from user A" while A is typing. The only way to fix this would be to change "Take over" to "Request to take over" and then wait for a response, etc.

However we decided (at a dev chat) to not deal with the courtesies involved in taking over post editing for now. In nearly all cases the users would communicate with each other before taking over, but we are not preventing them if they decide to (be rude) boot somebody unexpectedly.

[jackreichert]

3. Note that the post that loads is not the most recent autosave of the post, but equally importantly you are not shown the message stating this.

It seems that this is no longer the case. When trying to reproduce this I saw that when you take over it doesn't load the most recent, but it does show the message. I would say that this is enough for this ticket.

[r1k0]

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

• WordPress: 6.9
• PHP: 8.3.19
• Server: Apache
• Database: mysqli (Server: 11.4.9-MariaDB / Client: mysqlnd 8.3.21)
• Browser: Chrome 143.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Four 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps to Reproduce

• The same as provided by the reporter above.

Actual Results

1. ❌ Error condition doesn't occur (not reproducible).

Additional Notes

• As mentioned by @jackreichert, the post doesn't load the most recent version.
• But the user is informed that 'There is an autosave of this post that is more recent than the version below' and an option to view the autosave version.

Supplemental Artifacts

Screencast:
​https://files.catbox.moe/pxsjh3.mp4

[abhishekfdd]

Confirming the reproduction report from r1k0 in comment:9 and the earlier
note from jackreichert in comment:6 against current trunk (6.9). Both
reported symptoms are resolved:

1. The "There is an autosave of this post that is more recent than the version below. View the autosave" notice is shown after a takeover.

2. The notice is rendered by the standard autosave check on the edit screen — independent of how the editor was loaded — so the takeover path inherits it automatically. The check lives in both editor bootstrap files:

• Classic editor: src/wp-admin/edit-form-advanced.php, the wp_get_post_autosave() call followed by the `mysql2date( 'U', $autosave->post_modified_gmt, false ) > mysql2date( 'U', $post->post_modified_gmt, false )` comparison that emits the "View the autosave" notice.

• Block editor: src/wp-admin/edit-form-blocks.php, same timestamp comparison feeding the editor's autosave-exists state.

_admin_notice_post_locked() in src/wp-admin/includes/post.php
handles only the takeover modal itself and does not need to be
autosave-aware — by the time the takeover redirect lands on the
edit screen, the autosave check above runs as it would for any
other load.

3. The residual race — User A hasn't autosaved yet when User B clicks "Take over", so there is no server-side autosave for User B to be offered — was acknowledged as architectural in comment:1 (autosave runs on a fixed interval, A's pending changes only persist after B has already loaded) and explicitly declined as a fix path in comment:3 (the "request to take over" handshake was rejected at dev-chat). User A's unsaved keystrokes only exist in their browser at that moment; there is nothing on the server for core to load.

The related concern about User A's stale tab continuing to autosave
after a takeover and clobbering User B's changes is a different bug
and is tracked in #55659; it shouldn't gate this ticket.

Suggesting worksforme as the resolution.