Suggest mode 6: Bump payload schema to v2 (foundations)#77967
Suggest mode 6: Bump payload schema to v2 (foundations)#77967adamsilverstein wants to merge 1 commit intoadd-suggestion-modefrom
Conversation
v1 readers silently dropped operation types they didn't know about, which would cause a v2 payload with structural ops (block-insert-after, block-remove, block-move under #77434) to apply only its attribute-set operations. Refusing the payload outright instead surfaces an explicit "newer editor" notice and offers only Reject. The shape is unchanged: v1 payloads only ever carried attribute-set ops and remain valid as v2 payloads. The migration step in parseSuggestionPayload stamps the version field forward; no rewriting needed. Pre-versioned payloads are treated as v1. Refs #77434.
|
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. |
|
Size Change: +50 B (0%) Total Size: 7.92 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in f6c4e6f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25390203164
|
What
Bumps the suggestion payload
schemaVersionfrom 1 to 2 and tightensparseSuggestionPayloadto:schemaVersion > SCHEMA_VERSION) — surfaces an explicit "newer editor" notice instead of silently dropping unknown op types.schemaVersion < SCHEMA_VERSION) — pure version-field stamp; v1 payloads only ever carriedattribute-setops and remain valid as v2 payloads.schemaVersionfield as v1 (only the v1 implementation could have emitted it).This is plumbing for the structural-suggestion stack tracked in #77434. No user-visible change.
Why
Without the bump, a v1 reader receiving a v2 payload with
block-insert-after/block-remove/block-moveops would silently apply only theattribute-setops and drop the rest — a confusing partial-apply. Refusing the payload outright hands the user a clear "this suggestion was made by a newer editor" notice and only the Reject affordance.The shape is otherwise unchanged: v1 payloads carry only
attribute-setops, which are still valid in v2. The migration step inparseSuggestionPayloadis a no-op rewrite — it just stamps the version field forward.Testing the complete feature
To exercise structural suggestions end-to-end, check out the topmost branch in the stack (which contains every commit below it):
# Topmost branch in the stack: suggest-mode-6c-move-ui (PR #77979). git fetch origin suggest-mode-6c-move-ui git checkout suggest-mode-6c-move-ui npm install npm run dev npm run wp-env startTesting instructions
Then in
wp-admin:For the multi-peer scenario, open the same post in a second browser tab as a different user. Suggestions auto-saved on tab A appear in tab B's sidebar; Apply/Reject on tab B propagates back through the sync layer without the originating tab's interceptor reverting the apply (covered by
isAcceptedSuggestionChangefor attribute-set today; structural multi-peer accept hardening tracked as a follow-up).Stack
Refs #77434, #73411.