Adds a client→server schema-version handshake on every WS connect
and a per-item op-log rebuild path for the case where the server
ships a new SCHEMA_VERSION and finds older rows persisted in the
op-log.
Client side
- New web/src/lib/collab/schemaVersion.ts exporting `SCHEMA_VERSION`
(currently '1') with a documented bump rule covering Tiptap
extension changes, coordinated multi-package bumps, and Y.Doc
fragment-shape changes.
- wsProvider's defaultCollabUrl appends ?schema_version=...
Server side
- handlers_collab.go validates ?schema_version against
RoomManager.SchemaVersion() BEFORE upgrading the WS; mismatch
returns HTTP 400 with code "schema_mismatch". An empty query is
treated as legacy '1' for graceful deploys; once the server bumps
past v1, missing query becomes a 400 too.
- New RoomManager.SchemaVersion() getter.
- RoomManager.Join's setup-phase (under itemLock) now calls
maybeRebuildOnSchemaMismatch: if the latest persisted op-log row's
schema_version disagrees with the manager's current version, the
entire item op-log is pruned via PruneYjsUpdatesBefore. items.content
is canonical and untouched, so the lazy-seed path (TASK-1261)
re-encodes it into ops at the new schema on the next idle tick.
- New store method LatestYjsUpdateSchemaVersion.
Tests
- internal/collab/manager_test.go: three new tests (mismatch prunes,
clean version preserves op-log, post-rebuild connects are clean)
+ fakeOpLog gets LatestYjsUpdateSchemaVersion + PruneYjsUpdatesBefore.
- internal/server/handlers_collab_test.go: rejects-schema-mismatch
(400), accepts-explicit-match (101).
One round of Codex review (CLEAN with two NITs, both fixed).
xarmian
9b46be915a