fix: preserve blockType and id when filtering block data#15659
fix: preserve blockType and id when filtering block data#15659nehaaprasad wants to merge 1 commit intopayloadcms:mainfrom
Conversation
…plicate selected locales
DanRibbens
changed the title
|
The following test failed in CI:
It's possible this PR broke it, or it might just have been flaky. I tried restarting it, but there's a cache error in github actions. Sometimes that happens, and it's fixed with an empty commit. I couldn't do it because your branch/fork is protected. Could you take a look? I'd try an empty commit first, and if that test fails again, then the change broke it. Also, if you could create a test that replicates the original issue, that would be great! |
|
This issue drives our editors crazy on production for a while. We spend ages to come to the same fix as @naaa760 PLEASE release this! Our patch file, does the exact same, just different pattern: Together with #15658 using the blocks field should finally feel stable :) |
|
I created #15715, as the same issue actually happens when merging localized data as well. The fix is the same. So mine is superseeding this PR, we can also merge them together to give @naaa760 some credits as well? Added some extra tests in mine, and all are green on my local machine, could you please enable/approve the PR to run on CI? @GermanJablo |
GermanJablo
requested review from
GermanJablo
and removed request for
JessRynkar
|
Closed in favor of #15715 |
…lectedLocales (#15715) ## Summary - Fixes `mergeLocalizedData` dropping `blockType`, `id`, and `blockName` from non-localized blocks when the existing document has no blocks yet (e.g. after an initial autosave before blocks were added) - Fixes the same class of bug in `filterDataToSelectedLocales` - Not specific to `localizeStatus: true` — affects any collection using `publishSpecificLocale` with versioned blocks + autosave Supersedes #15659 — the bug actually exists in **two spots**: both `filterDataToSelectedLocales` (which #15659 addresses) **and** `mergeLocalizedData` (which #15659 misses). This PR fixes both, using direct property assignment instead of object spread for less overhead. ## Root cause In both `mergeLocalizedData` and `filterDataToSelectedLocales`, the recursive calls for non-localized blocks only iterate `block.fields`. But `blockType`, `id`, and `blockName` are internal metadata not present in `block.fields`. When `existingValue` is `undefined` (main doc has no blocks because autosave only wrote to the versions table), `blockData` falls back to `{}`, and the recursive call starts with an empty object — metadata is lost. When `existingValue` already has blocks, `blockData` contains `blockType` from the spread and the bug doesn't trigger. ## Fix After each recursive `mergeLocalizedData`/`filterDataToSelectedLocales` call for blocks, explicitly reattach `blockType`, `id`, and `blockName` from the incoming data. Direct property assignment (no extra object spread) for minimal overhead. ## Related - #15655 / #15659 — same bug class in `filterDataToSelectedLocales` (this PR includes that fix with a more performant approach) - #15642 / #15658 — sibling bug in `mergeLocalizedData` (unnamed groups losing data) ## Test plan - [x] Unit tests for `mergeLocalizedData` — 3 new tests covering empty existing doc, undefined block field, and happy path - [x] Unit tests for `filterDataToSelectedLocales` — new spec file with 5 tests covering block metadata preservation - [x] Integration test — creates doc without blocks, adds blocks, publishes with `publishSpecificLocale`, verifies `blockType` and `id` survive - [x] E2E test — same scenario through the admin UI + API 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: German Jablonski <43938777+GermanJablo@users.noreply.github.com>
3 participants
fix: #15655
What?
Why?
How?