Skip to content

Generalize the atomic schema-mutation fix to field insert/reorder #203

Description

@brylie

`FieldMenu.svelte`'s `insertField` (insert left/right) and `FieldManagerDialog.svelte`'s `moveField` (reorder) both build a whole replacement schema array from a caller-supplied reactive `schema` prop and call `updateCollectionSchema` directly. Two rapid schema edits — a reorder racing an insert, two reorders in quick succession, or an edit racing a concurrent collaborator's own field change — can each read a schema that's already stale by the time the second call writes, silently dropping the first change.

PR #200 (issue #189) fixed exactly this race for field-append by adding `records.ts`'s `appendCollectionField`, which reads `ymeta.get('schema')` fresh inside a `doc.transact` rather than trusting a snapshot (flagged by CodeRabbit during that PR's review). `insertField` and `moveField` still have the old, racy shape.

  • Add `records.ts` primitives for insert-at-index and reorder that read the current schema from Yjs inside `doc.transact`, mirroring `appendCollectionField`.
  • Repoint `FieldMenu.svelte`'s `insertField` and `FieldManagerDialog.svelte`'s `moveField` at the new primitives, dropping the schema-snapshot parameter the same way `appendCollectionField`'s callers already did.
  • Add a regression test for two rapid operations (e.g. a reorder racing an insert) from one initial schema snapshot, mirroring `appendCollectionField`'s test in `records.test.ts`.

Done when: field insert and reorder both read the schema atomically from Yjs at write time, proven by a regression test that two rapid operations from one snapshot don't drop either change.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions