Core Data: Avoid stale values when in autosave payloads#76337
Merged
Conversation
Mamaduka
added
[Package] Core data
|
Size Change: -39 B (0%) Total Size: 6.89 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 4170261. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22888176768
|
jsnajdr
reviewed
Mar 11, 2026
| await editorPage.bringToFront(); | ||
| await editor.canvas | ||
| .locator( 'role=textbox[name="Add title"i]' ) | ||
| .fill( 'Sample Page' ); |
Member
There was a problem hiding this comment.
After I fill "Sample Page" here, the editor will detect that the title is the same as the persisted title and will remove the title field from the edits? Now only the recent autosave has the "Sample Page 2" title. And it gets mistakenly carried over to the next autosave.
Just checking my understanding 🙂
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
jsnajdr
approved these changes
Mar 11, 2026
Member
jsnajdr
left a comment
jsnajdr
left a comment
There was a problem hiding this comment.
I think the original logic was overprotecting.
Reading the original discussion where there were already doubts about the autosave fallback, I'm confident that it didn't really have any useful function.
If a field has a valid value, it's either in the persisted record, or in the edited one. Where else would it be? There's no other source where the recent autosave could get it from.
Turns out that the recent autosave was only providing stale values and was causing a bug.
Member
Author
I came to the same conclusion. Tried testing the case where the previous autosave gets merged with the next. It doesn't happen, I think it's even prevented the REST API. Thanks for the testing and confidence check, @jsnajdr! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Closes #33758.
PR removes
autosavePostrecord from merge chain when building the new autosave payload, which fixes the bug with stale autosaves.Why?
When a user reverted a field (e.g., title back to its original value),
autosavePoststill retained the old value and overwrotepersistedRecord's correct value.I think the original logic was overprotecting. If the user doesn't intentionally restore the previous autosave, the core shouldn't try to merge it with the new one. Autosaves are meant to be snapshots -
{ ...persistedRecord, ...currentEdits }.Testing Instructions
PR includes e2e tests based on the issue's reproduction steps.
Testing Instructions for Keyboard
Same.