fix: restore falling back to current document values for undefined fields#16272
Merged
PatrikKozak merged 3 commits intopayloadcms:mainfrom Apr 15, 2026
Merged
Conversation
**Behavior prior to this change:** When restoring a version, `beforeValidate` field processing backfilled `undefined` fields from the current document data into the version data. This behavior is correct for partial updates (preserving unmodified fields), but incorrect for restore operations, where the version snapshot is the complete desired state. **Behavior with this change:** The desired fallback behavior during partial updates is retained, but `getFallbackValue` is skipped during restore operations denoted with the new request context `isRestoringVersion = true`. This removes the behavior where `undefined` fields are backfilled from the current document.
philipp-tailor
force-pushed
the
change-version-restore
branch
from
bdff78e to
6522bbe
Compare
PatrikKozak
changed the title
undefined fieldsundefined fields
PatrikKozak
approved these changes
Apr 15, 2026
Contributor
|
🚀 This is included in version v3.83.0 |
milamer
pushed a commit
to milamer/payload
that referenced
this pull request
Apr 20, 2026
…fields (payloadcms#16272) ### What? **Behavior prior to this change:** When restoring a version, `beforeValidate` field processing backfilled `undefined` fields from the current document data into the to-be-restored document data. This behavior is correct for partial updates (preserving unmodified fields), but incorrect for restore operations, where the version snapshot is the complete desired state. This is the current behavior on `main`: Note how the `Radio` field is not set in the first version, but set to `Test en` after the restore of said first version. https://github.com/user-attachments/assets/56467956-7caa-4363-989e-bcd1a663ce7a **Behavior with this change:** The desired fallback behavior during partial updates is retained, but the to-be-restored document no longer runs this fallback behavior. The restored document equals the document that the user triggered the restore for. Note how now the `Radio` field is not set again after the restore, just like it was when the first version was created: https://github.com/user-attachments/assets/0b5833b5-3694-4b10-9a11-f25f5c1a3b24 ### Why? When a user restores an old document version, the user's expectation is that the old document is what they are going to get after successful restore. It is unexpected if the document is a "frankenstein" version of the old document and the current document, especially since the user has no way to see the resulting document before the restore and can't know which attributes might be set from the current document as fallback value. ### How? `getFallbackValue` is skipped during restore operations denoted with the new request context `isRestoringVersion = true`. --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1214068985579207 --------- Co-authored-by: Patrik Kozak <35232443+PatrikKozak@users.noreply.github.com>
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?
Behavior prior to this change:
When restoring a version,
beforeValidatefield processing backfilledundefinedfields from the current document data into the to-be-restored document data. This behavior is correct for partial updates (preserving unmodified fields), but incorrect for restore operations, where the version snapshot is the complete desired state.This is the current behavior on
main: Note how theRadiofield is not set in the first version, but set toTest enafter the restore of said first version.restore.on.main.mp4
Behavior with this change:
The desired fallback behavior during partial updates is retained, but the to-be-restored document no longer runs this fallback behavior. The restored document equals the document that the user triggered the restore for.
Note how now the
Radiofield is not set again after the restore, just like it was when the first version was created:restore.with.PR.code.mp4
Why?
When a user restores an old document version, the user's expectation is that the old document is what they are going to get after successful restore. It is unexpected if the document is a "frankenstein" version of the old document and the current document, especially since the user has no way to see the resulting document before the restore and can't know which attributes might be set from the current document as fallback value.
How?
getFallbackValueis skipped during restore operations denoted with the new request contextisRestoringVersion = true.