Suggest mode 6: Bump payload schema to v2 (foundations)#77967
Suggest mode 6: Bump payload schema to v2 (foundations)#77967adamsilverstein wants to merge 8 commits into
Conversation
|
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: +134 B (0%) Total Size: 7.51 MB 📦 View Changed
|
|
Flaky tests detected in f6c4e6f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25390203164
|
f6c4e6f to
b9092d0
Compare
54bc0e5 to
b6a0a74
Compare
b9092d0 to
7259d48
Compare
Per-block debounced background save for Suggest mode. After a 1.5 s idle window, pending overlay edits persist as a note comment; subsequent edits on the same block update the existing note's meta rather than creating a new one, and a fully reverted overlay trashes the note. Saves on the same clientId run sequentially via a per-block promise queue, while different blocks run concurrently. Replaces the explicit SuggestionCommitBar toolbar button.
Move the auto-save subsystem's ref syncing out of render and into an effect, matching the store-interceptor fix, so the react-hooks rule against accessing refs during render passes. Prune the now-unused auto-save.js suppression along with the stale bulk-suppressions the stack carried before trunk's ESLint dependency bump. lint:js passes.
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.
…ations Bring the payload-schema-v2 foundations branch up to date with its base after autosave was cascaded onto latest trunk and reconciled onto phase-5b's REST architecture. Take the auto-save subsystem from the base (auto-save.js and its test): the base carries the dup-note concurrency fixes (synchronous commentId/syncedOps ref maps and the peer-resolution fresh-read via the note collection endpoint) that this branch's older copy predated. The v2 payload work is unaffected — it lives in provider.js (`schemaVersion: 2`) and the architecture doc, both of which merge cleanly on top. Keep the base's trunk-derived CHANGELOG version heading.
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 the complete Suggest-mode feature (structural suggestions + inline preview marks) end-to-end, check out the combined integration branch
try/suggest-mode-combined, which merges this stack (#77967 → #77979) with the inline-preview stack (#77869) on top ofadd-suggestion-mode:Testing 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.