13 Commits

Author	SHA1	Message	Date
xarmian	1dbe04399a	fix(store): optimistic concurrency + sibling broadcast for collection settings (BUG-2265) (#989) ... * fix(store): optimistic concurrency for collection settings writes (BUG-2265) Collection-level settings (e.g. quick_actions) were written by reconstructing the whole settings JSON from a caller's local Collection snapshot, and UpdateCollection replaced the column with no concurrency check. Two ItemDetails in the same collection (full-page pane host master + pane) hold independent snapshots and clobbered each other. Mirror the item optimistic-concurrency pattern (IDEA-1480): add CollectionUpdate.ExpectedUpdatedAt; when set, UpdateCollection re-reads updated_at atomically under the workspace write lock (SQLite BEGIN IMMEDIATE / Postgres advisory xact lock) and returns CollectionUpdateConflictError on a mismatch. Empty token keeps the legacy last-write-wins path unchanged for CLI/MCP/API callers. No DB migration — reuses collections.updated_at. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * feat(server): collection.updated broadcast + 409 conflict mapping (BUG-2265) - handleUpdateCollection boundary-validates expected_updated_at (400 on a malformed token) and maps store.CollectionUpdateConflictError to the shared update_conflict envelope (HTTP 409) — byte-identical wire shape to the item path, via the extracted writeUpdateConflictEnvelope helper. - Add the collection_updated EventBus type and publish it after a successful update so sibling ItemDetails / collection pages refresh their independent Collection snapshot proactively, shrinking the 409 window. Routed by Collection (slug) through the existing SSE visibility filter. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(web): 409-aware collection settings writes + sibling refresh (BUG-2265) - CollectionUpdate carries expected_updated_at; add isUpdateConflictError. - QuickActionsMenu sends the token and, on a 409, refetches the collection, re-appends the new action onto the FRESH settings, and retries once — no silent loss, no user-visible error. - EditCollectionModal captures the token at open-time (edge-gated seed so a concurrent broadcast can't wipe in-progress edits) and shows a non-destructive "changed elsewhere, reload" message on 409 rather than auto-merging a full-form edit. - Subscribe to collection_updated over SSE: ItemDetail and the collection page refresh their own Collection snapshot (gen/slug-fenced against the persistent pane host's no-remount switch), so siblings converge before the next save. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(store): harden collection optimistic concurrency + web fetch ordering (BUG-2265, Codex round 1) Address Codex review findings: - [P1] same-second clobber: now() is one-second precision, so two guarded writes in the same second kept an identical token. The accepted write now advances updated_at strictly past the token (only when now() hasn't already moved on), making a stale-token replay deterministically conflict. Add a same-second regression test. - [P1] tokenless-writer race on Postgres: the advisory lock only serialized writers that also took it. Replace it with a `FOR UPDATE` row lock on the in-tx re-read (Postgres) — SQLite's BEGIN IMMEDIATE already serializes every writer — so a concurrent tokenless UpdateCollection can't slip between the re-read and the UPDATE. - [P2] rename broadcast: only publish collection_updated when the slug is unchanged. A rename's old-slug event would make siblings refetch a dead slug (404) and a new-slug event can't reach old-slug visibility snapshots; renames are handled by the existing navigation path. - [P2] out-of-order refreshes: ItemDetail and the collection page now use a dedicated monotonic refresh counter so two rapid collection_updated fetches can't resolve out of order and clobber newer state (loadSeq/loadGeneration only bump on route/item loads). Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(store): make collection updated_at strictly monotonic for ALL writes (BUG-2265, Codex round 2) The previous same-second advance ran only on guarded updates, so a tokenless UpdateCollection could write the current second over a forced expected+1s, regressing the concurrency token and letting a stale guarded client clobber newer data (Codex P1). Route every collection update through one small transaction that re-reads updated_at (FOR UPDATE on Postgres; SQLite BEGIN IMMEDIATE covers it) and derives the new timestamp atomically: strictly advance past the row's current value when now() hasn't already moved on. This makes updated_at a reliable concurrency token for guarded AND tokenless writers. Add a tokenless-monotonic regression test. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: close remaining collection-concurrency gaps (BUG-2265, Codex round 3) - [P1] Board column reordering (handleGroupReorder) rebuilt the full schema from a stale local snapshot and wrote it with no token — a lost-update path identical to the bug being fixed. Now sends expected_updated_at and, on 409, refetches, re-applies the reorder onto the fresh schema, and retries once. - [P2] The workspace settings page seeded EditCollectionModal from a page-load-time collections list, so a change that predated editing produced a false 409. It now refreshes the list on collection_updated (seq-guarded). - [P2] collection.updated is now delivered to item-grant-only SSE subscribers for collections they can see — it's itemless but leak-free (only the slug), so guests' ItemDetail schema/settings snapshots converge too. Filter test extended. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(web): switch-safety + conflict-merge fixes for collection writes (BUG-2265, Codex round 4) - Board column reorder now ABORTS on a 409 (with a "reorder again" toast) instead of replaying a stale option order onto the fresh field, which would silently drop a concurrent option add/remove/rename. Reordering is cosmetic; never worth clobbering a real schema edit. Also captures ws/slug/base before the await and fences the write against a route switch. - QuickActionsMenu captures workspace + collection identity BEFORE the first await, so a mid-save navigation can't make the 409 refetch/retry target the wrong collection (no guaranteed remount). - Settings-page SSE refresh captures the workspace and drops the result if the workspace changed while fetching, so a slow refresh for workspace A can't overwrite workspace B's freshly loaded collection list. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(store): sub-second collection updated_at token, no future drift (BUG-2265, confirming pass #6) The same-second monotonic advance manufactured whole-second FUTURE updated_at values; sustained >1 write/sec on one collection drifted arbitrarily ahead of wall-clock. collections.updated_at is TEXT on both dialects and never compared lexically (only via time.Equal + display), so switch the update write to sub-second nowNano(): same-second collisions become near-impossible, so the token advances naturally. Keep a strict-monotonicity guard but step by a single NANOSECOND on the (now near-impossible) coarse-clock/step-back collision, so any drift is bounded to nanoseconds. Dual-dialect; covered by make test-pg. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(server): sanitize + always-broadcast collection event (BUG-2265, confirming pass #2,#3) - #2 (P1): collection_updated is delivered to item-grant guests, but the event carried ActorName/Source, leaking the owner's identity + edit source. Strip them — publishCollectionEvent now emits workspace + slug (+ new_slug) only. - #3 (P2): always broadcast (including on rename), routed by the OLD slug and carrying the NEW slug via a new Event.NewSlug field, so remote tabs on the old slug can re-target instead of silently 404ing on their next action. Tests: assert no actor/source leak on a settings update; assert a rename routes by old slug + carries new_slug. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(web): decisive switch-safety + rename handling for collection writes (BUG-2265, confirming pass #1,#3,#4,#5) - #1 (P1): EditCollectionModal captures the target collection id/slug/name/ws + updated_at when the form is SEEDED, and handleSave/handleArchive now operate on that captured identity (not the live props). The seed effect re-seeds when the collection IDENTITY changes (not on a same-id broadcast refresh), so a reused route can't leave A's form saving/deleting to B. - #3 (P2): on a rename event the collection route navigates to the new slug (preserving the pane query) and ItemDetail refetches by new_slug; the SSE event type carries new_slug. - #4 (P2): the reorder-conflict path refetches the collection (reseeds the token) before prompting, so a missed SSE event doesn't make every retry 409 forever. - #5 (P2): QuickActionsMenu only invokes oncollectionupdated when the live workspace/slug still match the captured identity, so a reused route can't assign an old response to the newly-navigated page. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(server): nano token round-trip, rename visibility, publish-before-migration (BUG-2265, confirming pass 2) Address the round-2 confirming-pass findings (server-only): 1. (P2) The shared update_conflict envelope formatted actual_updated_at with second precision (time.RFC3339), truncating the now sub-second collection token so the client's retry token never matched — a permanent 409 loop. Format with time.RFC3339Nano. Item tokens are zero-nanosecond, so RFC3339Nano emits no fractional part — the item 409 wire shape is byte-identical and the item path still compares via time.Equal. Added a test that the returned token round-trips as a usable retry token. 2. (P2) Rename events are routed by the OLD slug, but a subscriber that revalidated after the rename only has the NEW slug in visibleSlugSet, so the visibility check dropped the event before the new_slug branch. Accept a rename when EITHER the old slug or the (authorized) NewSlug is visible; downstream item-grant gating uses whichever slug is visible. Filter test extended. 3. (P2) The collection_updated event was published only after field migrations succeeded, but UpdateCollection already committed (updated_at advanced). On a migration failure clients got a 500 and no refresh, leaving siblings with stale tokens that 409 blindly. Publish on the commit (before the migration), so siblings always resync regardless of migration outcome. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: atomic collection update+migration; modal same-id rename retarget (BUG-2265, confirming pass 3) Address the round-3 confirming-pass findings; defer cross-tab rename RE-NAVIGATION to BUG-2272 (placeholder) per coordinator. 1. (P1) Migration atomicity. UpdateCollection committed the schema + concurrency token BEFORE MigrateItemFieldValues ran, so a migration failure returned 500 with the row already changed → the retry was guaranteed to 409 and item values were left inconsistent with the committed schema. Made the two ATOMIC: extracted applyFieldMigrationsTx and run it inside UpdateCollection's own transaction (after taking the workspace seq lock), so a migration failure rolls back the schema AND the token — nothing changes, the retry works. The handler now passes migrations through instead of running them separately, and publishes the event only after the fully-atomic commit. store/tx work → make test-pg run green. 2. (P2) EditCollectionModal same-id rename. The round-1 identity capture ignores same-id prop refreshes (to preserve edits), but a concurrent RENAME changes the slug (not the id), so handleSave/handleArchive PATCHed a dead slug → 404 before the token could 409. On a same-id prop change whose slug changed, the seed effect now retargets the endpoint slug + re-captures the token WITHOUT reseeding the form (in-progress edits preserved). Deferred (BUG-2272, TODO comments added, already broken on main — no regression): - ItemDetail full-page item URL/collSlug not retargeted after a remote rename. - Collection route chained-rename events during SSE replay landing on a dead intermediate slug. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(web): keep seeded token on same-id rename retarget (BUG-2265) On the EditCollectionModal same-id rename branch, retarget the endpoint (slug/name/ws) only — drop the token re-capture. Re-capturing let a later handleSave succeed against the renamed collection and apply the modal's stale pre-rename full form, silently REVERTING the concurrent rename (the exact stale-snapshot clobber BUG-2265 prevents). Keeping the seeded token means a concurrent rename correctly yields a 409 → the non-destructive "collection changed, reload" message. Slug-retarget without token-recapture gives both: no 404 (right URL) and no clobber (409 fires). Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: lock-order deadlock + unified collection-snapshot fences (BUG-2265, confirming pass 4) 1. (P1) DEADLOCK regression. UpdateCollection's atomic migration path took the collection-row FOR UPDATE lock and THEN the workspace seq lock, but item creation takes them in the reverse order (workspace advisory lock first, then the collection-row FK lock on INSERT) — a concurrent item-create + schema-migration ABBA-deadlocks on Postgres. Fix: acquire the workspace seq lock BEFORE the collection-row FOR UPDATE (matching item-create's order). Every store path that locks both now takes them workspace-seq → collection-row (tryCreateItem, UpdateItem, MigrateItemFieldValues, UpdateCollection). Added a concurrency regression test (item-create racing schema-migration); make test-pg green. 2+3. (P2) Cross-generation fence gap. The SSE collection refresh and route/item loads used SEPARATE counters, so a stale in-flight load could complete after a fresh SSE refresh and revert the collection + its concurrency token. Unified to a SINGLE monotonic collection-snapshot generation in BOTH the collection route and ItemDetail — every collection-snapshot write (loadCollection/loadData, the SSE refresh, reorder, and the quick-action/edit-modal callbacks) bumps it on start and gates its assignment on "still latest". ItemDetail's load keeps a switch-escape so a stale refresh for the OLD collection can't block loading a NEW one. Settings page unified the same way over its collections-list writes. 4. (P2) Settings page fed a stale editingCollection to the edit modal after a remote rename (its prop never changed → the same-id-rename retarget never fired → 404). The unified refresh now re-points editingCollection at the refreshed object for the same id, so the modal's retarget fires. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: emit item-changes signal on field migration; QuickActions retry-by-id (BUG-2265, confirming pass 5) 1. (P1) A collection update that runs a field migration mutates item `fields` JSON and advances item `seq`, but only collection_updated was published — open item views refreshed collection METADATA and returned without reconciling the migrated items, so clients kept stale field JSON under the new schema and a later full-fields item update could UNDO the migration (a clobber). UpdateCollection now returns the migrated-item count; when > 0 the handler ALSO emits the existing bulk item-mutation signal (items_bulk_updated, Op=migrate) so open views reconcile via /items-changes. Fires only when the migration touched >= 1 item — a pure settings/quick-actions update emits nothing extra. No store SQL/locking change (Go signature + count plumbing only); make test / make test-pg both green. 2. (P2) QuickActionsMenu's 409 retry GET-by-slug 404s if the competing update renamed the collection. Resolve the fresh collection by STABLE id (list + find by id) before re-appending + retrying, mirroring EditCollectionModal's identity approach; the result-propagation guard is now id-based too so a rename doesn't spuriously drop it. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: uniform sweep of item-grant delivery, rename routing, and 409/404 retries (BUG-2265, confirming pass 6) One pattern-sweep instead of per-site patches. Audited every event this PR publishes and every client retry path, applying three patterns uniformly: PATTERN A (item-grant SSE reconcile) + B (old-slug rename routing): instead of a SEPARATE items_bulk_updated migration event (which carries op/count for items an item-grant subscriber can't see and isn't rename-routed), FOLD a SANITIZED `items_changed` bool onto collection_updated — already item-grant-delivered (round 3) and already old-slug-routed with new_slug (round 2). On it the client triggers a /items-changes deltaSync (server-filtered to the caller's grants) and ItemDetail refetches its open item, so item-grant EDITORS reconcile migrated field JSON — closing the clobber where a stale full-fields update would UNDO the migration. Leak surface: "a collection you can see items in changed [+ renamed + had item changes]" — a bool, no per-item data. Removed the round-5 items_bulk_updated publish. The pre-existing items_bulk_updated (archive/move) is untouched and correctly stays suppressed for item-grant users. PATTERN C (409 AND 404 in retries): a competing RENAME can 404 a slug-targeted write before it can 409, bypassing recovery. Added isNotFoundError / isConflictOrNotFound helpers; every write/retry path now treats BOTH: QuickActions save resolves-by-id and retries on either; board reorder reseeds-by-id and aborts on either; EditCollectionModal save shows the reload prompt and archive resolves-by-id and retries on either. Tests: server asserts collection_updated sets items_changed on migration (not on settings-only) and stays sanitized; the SSE-filter test asserts the migration variant reaches item-grant subscribers for a visible collection; web unit tests assert 404/409 classification and a real component-driven not_found -> resolve- by-id -> retry in QuickActionsMenu. make test / make test-pg / npm run test all green. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: stable collection-ID identity for collection events + request-based items_changed (BUG-2265, confirming pass 7) 1. (P1) Collection events were identified only by MUTABLE, reusable slugs, and events replay — so a stale rename event's old slug, once re-owned by a DIFFERENT collection, could pass a slug-based match and misroute a client (navigate away / load the wrong schema) or leak the new slug. Fix at the ROOT: carry the STABLE CollectionID on collection_updated (Event.CollectionID) and match by ID everywhere: - Server visibility: sseEventVisibleFor matches collection_updated on a new visibleCollIDSet (built from the same VisibleCollectionIDs), not the slug — so an event for a collection the subscriber can't see by ID is dropped even if its (reused) slug is in visibleSlugSet. Filter test proves the slug-reuse drop. - Clients: ItemDetail and the collection route match `event.collection_id === <their collection>.id`, not slug. Slug(s)/new_slug stay only for the rename-navigation URL. Settings refreshes its whole list (already id-safe). 2. (P1) items_changed was keyed off the affected-ROW count, delivered to item-grant subscribers → a subscriber whose own items were unaffected could infer that HIDDEN items matched the migrated value. Now keyed off whether a field MIGRATION WAS REQUESTED (len(input.Migrations) > 0), independent of row count — leaks nothing about hidden item values. Reverted round-5's UpdateCollection count-return (no longer needed). Test: a migration matching ZERO items still sets items_changed. Deferred with markers: - NOTE(BUG-2273) at ItemDetail's reconcile-skip AND updateField: the web editor's full-fields field write lacks item-level OCC (never adopted IDEA-1480/v0.14), so the migration reconcile is best-effort. - TODO(BUG-2272) at the reorder 404 reseed: it refreshes `collection` but not the route `collSlug` (renavigation, deferred). Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix: archive OCC (no destructive wrong-target) + settings load fence (BUG-2265, confirming pass 8) 1. (P1) EditCollectionModal handleArchive resolved the target by stable id but the server DELETE re-resolves by the MUTABLE slug — a rename that re-owned that slug before the delete landed would archive the WRONG collection. Close the TOCTOU with an expected_updated_at OCC on the delete, mirroring the update OCC: DeleteCollection re-reads updated_at under a lock (FOR UPDATE on Postgres) and 409s on mismatch; the handler validates the token + maps the 409; the client sends it as a query param; handleArchive passes the seeded token (and the fresh token on the resolve-by-id retry). A reused slug or a concurrently-changed target now yields a clean 409 → the reload message, never a wrong-collection archive. Server test: stale token 409s (and the collection survives); current token 204s; malformed 400s; no token 204s. 2. (P2) settings load(): the generation was bumped AFTER awaiting setCurrent, so a slow load for workspace A could resume after B's load and clobber B's name/context/collections/members. Capture a dedicated loadGen at load() ENTRY (before any await) and fence EVERY continuation on it; the collections write additionally respects collectionsGen so it can't revert a fresher SSE refresh. Using a dedicated loadGen (not the SSE-shared collectionsGen) means an SSE collections-refresh mid-load doesn't drop the name/members writes. Deferred: TODO(BUG-2272) at the collection route's rename-navigation site — the global collectionStore (sidebar/pickers) isn't refreshed and the workspace layout ignores collection_updated, so the sidebar keeps the dead slug. Layout- level renavigation, deferred. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra * fix(web): dedicated item-snapshot fence + id-based rename comparisons in ItemDetail (BUG-2265, confirming pass 9) One comprehensive ItemDetail async-snapshot fence sweep so this file's item/ collection fencing is uniform and ID-based. 1. (P1) The migration item-refetch and loadData shared loadGeneration, so the refetch could apply migrated fields and then a stale loadData response overwrite them (a later full-fields edit then undoes the migration). Added a DEDICATED itemGen (separate from loadGeneration and collectionGen), bumped at the start of BOTH loadData's item load AND the migration refetch, and gated BOTH `item = ` writes on "still latest itemGen" — neither can stale-overwrite the other. Swept the other PASSIVE item snapshot-refreshes onto itemGen too (SSE item_updated/archived/restored, onSync deleted/incremental/full, the collab refresh) so they're ordered against each other and the migration/load. 2. (P2) A settings update that follows a rename before the rename fetch completes requested the OLD slug and bumped collectionGen, cancelling the valid rename fetch. Fetch slug is now `event.new_slug || event.collection || slug`. 3. (P2) The loadData collection fence-escapes compared the stale load's SLUG vs the freshly-renamed snapshot's slug (they differ on a rename → escape let the stale result overwrite). They now compare stable collection IDs; the SSE refresh's post-fetch identity check is id-based too. Audit (site -> generation -> id?): every PASSIVE snapshot-refresh (loadData item+collection, migration refetch, SSE x3, onSync x3, collab) bumps the correct dedicated gen (item->itemGen, collection->collectionGen) and compares identity by id. The DELIBERATE user/action writes (title/field/tag/assignee/role/content/ link/version/restore saves) keep loadGeneration + item-id switch-safety; their item-snapshot concurrency vs the migration refetch is the deferred item-OCC gap (BUG-2273, best-effort) — reordering them last-started-wins is orthogonal to that. Claude-Session: https://claude.ai/code/session_01EZ6yr6pAUFb1uffan912ra	2026-07-21 09:43:05 -04:00
xarmian	bcf5e6519e	fix(web): render SSE connection-status indicator (TASK-2027) (#880) ... * fix(web): render SSE connection-status indicator (TASK-2027) * fix(web): initialize follower-tab SSE status via handshake (TASK-2027)	2026-07-09 15:05:34 -04:00
xarmian	dfd3811eee	feat(api): bulk-mutation endpoint + single SSE batch event (TASK-1668) (#669) ... * feat(api): bulk-mutation endpoint + single SSE batch event (TASK-1668) Add POST /workspaces/{ws}/items/bulk accepting item IDs + a verb (archive, move, tag, untag, set-priority, assign). The lane-header bulk actions operate on a whole filtered lane, so the endpoint emits ONE items_bulk_updated SSE event and ONE item.bulk_updated webhook for the batch instead of per-item fan-out. Reuses the existing store paths (UpdateItemWithPreCheck / MoveItem / DeleteItem) rather than re-implementing writes; the open-children guard runs per status-bearing move exactly as the single PATCH path does (force-overridable). Per-row failures are collected into the response envelope (updated/failed/total) rather than aborting the batch. Editor/owner gated. Frontend client + TS types follow in TASK-1669; UI wiring in TASK-1672. Parent: PLAN-1667. * fix(api): per-item visibility + collection-move guard on bulk endpoint per Codex review (round 1) - Enforce per-item collection visibility (checkItemVisible) in the bulk loop so a member with collection_access="specific" can't bulk-mutate items in hidden collections by guessing refs; report invisible rows as not-found. Also gate the move target collection on visibility. - Route bulk collection moves through MoveItemWithPreCheck with the open-children guard (destination schema), closing the bypass where a collection move + terminal status could mark a parent terminal with open children. Status-only moves already ran the guard. - Tests: status-move + collection-move guard coverage (reject + force override + mutation-safety). * fix(web): consume items_bulk_updated SSE event per Codex review (round 2) The bulk endpoint emits one items_bulk_updated event, but the SSE service only listened for the fixed ITEM_EVENTS list — so a bulk mutation left other tabs/sessions stale until an unrelated sync fired. Route the batch event through the existing sync_required path: it carries item_ids + a max seq but no per-item field payload, so an incremental /items-changes delta reconciles every affected row by seq. Broadcast so peer tabs reconcile too. * fix(api): scope bulk SSE event per-collection, drop item_ids per Codex review (round 3) The batch event published with an empty Collection, which the SSE filter treats as workspace-level: restricted members received bulk events for hidden collections (leaking item_ids/op/count) while guests with grants were dropped entirely and stayed stale. Emit one items_bulk_updated event per affected collection with Collection set, so the existing visibility filter routes it like any collection-scoped event. Drop per-item IDs from the SSE payload — a batch can't be item-grant-filtered for guests on a broadcast bus, so IDs would leak; recipients reconcile via the /items-changes delta, which is visibility-filtered server-side (Seq carries the cursor). The webhook (a trusted workspace integration) keeps the full id list. Test asserts the event is collection-scoped and carries no item_ids. * fix(api): bulk collection move notifies both source and target scopes per Codex review (round 4) A cross-collection move only emitted a batch event for the target collection, so a restricted member watching the source lane wouldn't reconcile the item leaving it. Notify both the source and target collection scopes for moves (still no per-item IDs). Test asserts both events fire. * fix(api): suppress itemless batch SSE events for item-grant-only subscribers per Codex review (round 5) A guest/restricted member with only item-level grants in a collection could still receive the collection-scoped items_bulk_updated event (itemless), learning op/count/timing for items they can't see. Extract the SSE visibility filter into sseEventVisibleFor and add a rule: itemless collection-scoped events go only to subscribers with FULL collection access; item-grant-only subscribers reconcile their granted items via the next resume/reconnect /items-changes sync instead. Adds a unit test covering the visibility matrix. * fix(api): validate status override against target schema on bulk collection move per Codex review (round 6) A status override on a collection move was applied after MigrateFields but never validated against the target schema, so an out-of-options value (e.g. status=bogus) could be written. Run ValidateFields on the final field map before the move. Test asserts the invalid value is rejected per-row and the item stays put.	2026-05-30 18:41:55 -04:00
xarmian	076fb9b2e7	feat(comments): comment editing backend — user_id, UpdateComment, PATCH, SSE (TASK-1663) (#665) ... * feat(comments): comment editing backend — user_id, UpdateComment, PATCH, SSE (TASK-1663) Foundation for comment editing (PLAN-1662). No migration — comments.user_id already exists (012_users.sql) but was never written or exposed. - Populate user_id on create/reply: CreateComment takes an explicit userID param (passed from currentUserID by the handlers, not via the request body so it can't be spoofed). Expose user_id on models.Comment + all comment SELECTs/scans. The workspace export path is left as-is — imported comments keep NULL user_id (admin-only edit), matching the pre-identity fallback. - Store.UpdateComment(id, body): replaces body + bumps updated_at; the comments_fts_update trigger re-indexes. - PATCH /workspaces/{ws}/comments/{commentID}: author-or-admin only (canEditComment), rejects empty body. Editing is an authorship op, distinct from delete (item editors). NULL user_id → admin-only. - comment_updated SSE event: broadcast from the handler; added to the web sse allowlist + ItemTimeline refresh set. - web: api.comments.update(), Comment.user_id type. Tests: author edits own (200), non-author non-admin (403), admin edits anyone (200), empty body (400), NULL-user_id comment is admin-only. Parent: PLAN-1662. * fix(account): detach authored comments on account deletion per Codex review (round 1) Now that TASK-1663 populates comments.user_id (FK to users.id), DeleteAccountAtomic would fail on the FK for any user who authored a comment. Null comments.user_id for the user before deleting the row — comments live on in soft-deleted/other workspaces; the display-name author is preserved and the comment just becomes admin-only to edit. Regression test added.	2026-05-30 12:38:57 -04:00
xarmian	54203087d0	feat(web): leader-elected SSE + cross-tab BroadcastChannel (TASK-1359) (#506) ... * feat(web): leader-elected SSE + cross-tab BroadcastChannel (TASK-1359) Multiple tabs of the same workspace now share a single SSE connection via navigator.locks. Per DOC-1342 design decision #2: one leader holds the EventSource, peer tabs receive deltas via BroadcastChannel. - Each connecting tab opens a BroadcastChannel `pad-sync-{ws}` and races for an exclusive Web Lock on `pad-sse-leader-{ws}`. - The lock-holder opens the EventSource and forwards every event to local callbacks AND broadcasts to peer tabs. The browser's own-message filter keeps the leader from re-dispatching its own messages on the way back. - Peer tabs subscribe to the channel and dispatch leader-forwarded events to their local callbacks. They don't open EventSources while a leader exists, so the browser sees ONE /api/v1/events connection per workspace per browser regardless of tab count. - On leader-tab close, navigator.locks releases the lock automatically and a queued peer takes over (opens its own EventSource) without manual intervention. - Connection status is also broadcast so peer tabs surface the same connected / reconnecting / unauthorized indicator the leader sees. Fallback: browsers without navigator.locks (very old / non-browser environments) skip the election and every tab opens its own EventSource — N× traffic but correct. The public API (onItemEvent, onSyncRequired, status, etc.) is unchanged, so existing callers — sync.svelte, collection page — just work. Parent: PLAN-1343. See DOC-1342 design decision #2. * fix(web): gate BroadcastChannel on navigator.locks support (Codex round 1) [P1] When BroadcastChannel is available but navigator.locks is not, every tab falls back to per-tab EventSource AND opens the same shared channel. Each tab handles its local SSE event AND receives its peers' broadcasts — item callbacks fire N times across N tabs, producing duplicate toasts and refetches. Gate BC opening on `leaderElectionSupported()` (which checks for navigator.locks). Without leader election, the per-tab EventSource still delivers events locally; we just don't fan out — correct and avoids the N× duplication. Parent: PLAN-1343. * fix(web): leader promotion sync + BC close on fallback (Codex round 2) - [P1] When a peer tab is promoted to leader (the old leader's tab closed), the new EventSource opens with no Last-Event-ID so the server can't replay events from the gap. Query navigator.locks BEFORE requesting the lock; if the slot is already held, classify ourselves as a future "promotion" and fire sync_required on grant so consumers (syncService, the collection page) backfill via /items-changes. First leaders on fresh page loads don't fire — bootstrap already runs a sync — and any mis-classification is idempotent + cheap. - [P2] The lock-rejection fallback path now closes the BroadcastChannel before opening per-tab SSE. Without this, two tabs that both reject the lock would each open their own EventSource AND keep receiving each other's broadcasts, firing callbacks N times. Also triggers sync_required since we may have missed events while the rejection landed. Parent: PLAN-1343. * fix(web): grant-delay fallback for promoted-leader classification (round 3) [P1] Two tabs starting simultaneously can both query the lock state and see "no holder", so both set queryPromoted=false. One wins the request, the other queues. When the queued tab eventually gets promoted, queryPromoted=false would skip the sync_required, missing events from the gap between the old leader's close and the new EventSource. Add a grant-delay signal: record `performance.now()` before requesting, and treat any callback that fires more than 100ms later as a promotion. Uncontested lock grants are sub-millisecond; a queued tab takes at least the previous leader's full session. Final `promoted` is `queryPromoted || grantDelay > 100`, catching both the "slot-already-held-at-query-time" case AND the "simultaneous-startup-race" case. Parent: PLAN-1343. * fix(web): defer promoted-leader sync until EventSource connects (round 4) [P1] Promoted/fallback leaders called dispatchSyncRequired immediately after `new EventSource(...)`, before the replacement SSE stream was actually subscribed server-side. A mutation between the /items-changes snapshot (triggered by the sync) and the new stream's first received event could be missed by BOTH paths. Defer via a `pendingSyncOnConnect` flag set in the promotion / fallback paths; the EventSource's onopen and `connected` listeners fire the sync only after the stream is live. Whichever event arrives first claims the pending flag. Parent: PLAN-1343.	2026-05-11 20:58:25 -04:00
xarmian	bd8667eadf	feat: seq-stamped SSE events + stale-event short-circuit (TASK-1358) (#505) ... * feat: seq-stamped SSE events + stale-event short-circuit (TASK-1358) ## Server - events.Event gains a `Seq int64` field (omitempty). Server populates it on item lifecycle events so SSE consumers can reason about ordering and contiguity against their /items-changes cursor. - publishItemEventWithName takes seq as a parameter; all call sites in handlers_items.go pass the item's current seq: - item_created → item.Seq - item_updated → updated.Seq - item_archived → re-fetched via GetItemIncludeDeleted (DeleteItem bumps seq but doesn't return the updated row) - item_restored → restored.Seq - move target → moved.Seq ## Web - ItemEvent gains optional `seq` (matches the server's omitempty). - localIndex.classifySSEEvent(ws, event) returns 'no-seq' | 'stale' | 'contiguous' | 'gap'. The collection page uses this to short-circuit duplicate / replayed events the server's replay buffer re-delivers after tab-resume. Non-stale events still call deltaSync because the SSE wire payload only carries metadata, not the row data; classify does NOT advance the cursor (applyDelta with real row data is the only path that does — preserving the IDB invariant from TASK-1356). Parent: PLAN-1343. * fix(events): version-restore item_updated event carries seq (Codex round 1) Version-restore in handlers_item_versions.go was publishing the item_updated event directly via events.Publish without Seq, bypassing the new seq-stamped SSE contract from TASK-1358. localIndex's classifySSEEvent would always return 'no-seq' for those events, forcing a generic /items-changes refetch instead of allowing the stale/gap fast paths. Now passes updated.Seq from the store response. Parent: PLAN-1343.	2026-05-11 20:29:50 -04:00
xarmian	578494dc43	fix(web): break sse↔sync circular dep via callback inversion (TASK-1242) (#445) ... Rolldown's stricter import diagnostics (introduced in TASK-1238 via Vite 8) flagged that `sync.svelte.ts` was both statically imported from 5 routes/components AND dynamically imported from `sse.svelte.ts`. Rolldown's warning: [INEFFECTIVE_DYNAMIC_IMPORT] sync.svelte.ts is dynamically imported by sse.svelte.ts but also statically imported by [5 files], dynamic import will not move module into another chunk. The original task body's first-cut fix ("convert the dynamic import to static") was wrong: the dynamic import wasn't there for code- splitting — the inline comment said "to avoid circular dependency", and indeed sync.svelte.ts statically imports `sseService`, so a reverse static import would close the cycle. Real fix: callback inversion. Mirror the existing `onItemEvent` pattern by adding `onSyncRequired(callback)` to sseService. Have syncService subscribe in its `init()` instead of sseService calling syncService directly. Net result: Before: sse →(dynamic import)→ sync ──╮ sync ─(static import)─→ sse ←──╯ (circular, papered over) After: sse exposes onSyncRequired() sync subscribes on init(), receives sync_required pings sse has zero imports of sync.svelte.ts (static or dynamic) Behavior is identical: • sse_required server event still triggers `syncService.triggerSync()` • sync.svelte.ts still owns the sync coordination decision tree • Init order is fine — both modules are evaluated as singletons at module-load time; subscription happens during syncService.init() which workspace +layout.svelte calls in onMount, well after both modules have settled Verified: • `npm run build` — INEFFECTIVE_DYNAMIC_IMPORT warning is gone; Rolldown bundle build went from 5.91s → 2.90s as a bonus • `make check` — golangci-lint + go test + npm run build + svelte-check, 0 errors, same 6 pre-existing warnings • Manual UI verify — SSE still works (collection page real-time updates, child item progress, comments/reactions, timeline) Spawned [[TASK-1243]] for a separate pre-existing bug surfaced during this manual verify: the item DETAIL page never subscribed to sseService.onItemEvent, so live title/field updates from other clients don't propagate until manual refresh. Out of scope for this PR.	2026-05-08 08:15:44 -04:00
xarmian	69262c3b53	feat(server): periodically revalidate SSE subscriber membership (TASK-670) (#194) ... * feat(server): periodically revalidate SSE subscriber membership (TASK-670) handleSSE checked workspace access only at connection time. A removed member kept receiving live events until they manually disconnected — or, more commonly, indefinitely, because browser EventSource auto- reconnects and the replay buffer filled any gaps. An owner who revoked access had no way to stop the leak without restarting the server. - New 60s membership revalidation ticker inside the SSE select loop. - Store.sseSubscriberStillHasAccess mirrors RequireWorkspaceAccess's access matrix: fresh install bypass, admin role, direct membership, guest grants, legacy workspace-scoped API token. DB errors fail OPEN (keep connection) so a transient blip doesn't bounce every open tab; membership-absent fails CLOSED. - On revocation we send the client a well-known {type:"unauthorized"} event with a human-readable reason BEFORE closing the stream, so frontend EventSource handlers can route to login / dismiss the workspace instead of tight-looping to reconnect. - sseMembershipRevalInterval is a package-level var so tests can shrink it; pinned to the 30-300s reasonable range. - Unit test exercises every branch: admin, active member, outsider, removed member, guest-grant (skipped when default collections aren't seeded), unauthenticated, legacy token scoped to same workspace, and legacy token scoped to a different workspace. Parent: PLAN-643 (OSS Security Hardening). * fix(web): handle server-emitted 'unauthorized' SSE event in client (TASK-670) Addresses Codex P2 on PR #194: the server emits `{type:"unauthorized"}` before closing a revoked stream, but the Svelte SSE service only listened for "connected", "sync_required", and item events. Without a handler, the default `EventSource.onerror` would auto-reconnect indefinitely on the next /api/v1/events request — exactly the tight-loop the server event was meant to prevent. - New 'unauthorized' SSEStatus so surrounding UI can react (e.g. redirect to workspace list or show a "revoked" toast). - Dedicated listener: on unauthorized, set status to 'unauthorized', close the EventSource explicitly (this prevents browser auto- reconnect), and null out currentWorkspace so a later connect() doesn't treat the closed connection as "already connected". Parent: PLAN-643 (OSS Security Hardening). * fix(server): recompute SSE visibility on each revalidation tick (TASK-670) Addresses Codex P1 on PR #194: previous revision only rebuilt the filter maps at connect time, so a user whose scope was NARROWED mid-stream (role downgraded to viewer, collection access tightened to "specific", item grants revoked) kept receiving events from collections they no longer had access to. Revocation-of-membership was caught, but scope-tightening was not. - Extract the filter-map computation into a new sseVisibility struct + (*Server).computeSSEVisibility method. Same logic as before, just reentrant so it can be re-run on a live connection. - Store the snapshot in a local `vis` variable captured by the sseEventVisible closure (reads the CURRENT snapshot, so the next event dispatched after a tick sees the new permissions). - On every revalidation tick where the subscriber still has access, call computeSSEVisibility again and reassign `vis`. The cost is one GetCollection + one GuestVisibleResources + friends per tick per connection — acceptable at the 60s cadence. - New TestComputeSSEVisibility_ReflectsCurrentGrants verifies that a second call after membership revocation returns a different snapshot (isGuest flip), pinning the regression. Parent: PLAN-643 (OSS Security Hardening). * fix(server): jitter first SSE revalidation tick to avoid stampedes (TASK-670) Addresses Codex P2 on PR #194: the earlier comment promised jitter but the implementation wired a plain time.NewTicker(revalInterval). Every stream then revalidated on a cadence tied to its connect time, which synchronizes whenever a wave of clients connects close together (post- deploy reconnect storm, login wave, cron-driven dashboard refresh). The resulting periodic :00/:60 DB load spike is the exact anti-pattern the comment warned about. - Swap the Ticker for a Timer. First fire is delayed by a random uniform [0, revalInterval) window using math/rand so connect-time coincidence doesn't translate to revalidation-time coincidence. - After the first fire, Timer.Reset(revalInterval) re-arms at the regular cadence — the jitter from connect-time is persistent for the lifetime of the connection, no need to re-jitter every tick. - math/rand is fine here: this is load-spreading, not a security primitive, so a deterministic-at-boot PRNG is acceptable. Parent: PLAN-643 (OSS Security Hardening). * fix(server): re-fetch user during SSE revalidation to catch admin demotion (TASK-670) Addresses Codex P1 on PR #194: sseSubscriberStillHasAccess early- returned on currentUser(r).Role == "admin", but currentUser(r) is the user snapshot cached in request context at SSE connect time. An admin demoted mid-stream via /api/v1/admin/users/{userID} would keep the admin short-circuit forever — the exact "admin forever" bug the revalidation loop was meant to close. - Re-fetch the user via s.store.GetUser(cachedUser.ID) at the start of each revalidation pass so role changes, disabled flags, and account deletions take effect on the next tick. - User deleted → revoke. - User disabled (IsDisabled) → revoke. Previously a disabled admin's stream also leaked. - All downstream checks (admin short-circuit, membership lookup, grant check) use the fresh copy. Tests: - TestSSESubscriberStillHasAccess_AdminDemotion: bootstrap admin, hand it to the request context, then demote to "member" in the DB and verify access flips to false. Without the fresh fetch, this test passes even though the real system leaks — pins the regression. Parent: PLAN-643 (OSS Security Hardening). * fix(server): use fresh user for SSE visibility computation too (TASK-670) Addresses Codex P1 on PR #194 (companion to the previous commit): computeSSEVisibility called visibleCollectionIDs(r, ...), which reads currentUser(r).Role — the cached snapshot placed in request context when the SSE connection opened. A global admin demoted to "member" mid-stream while keeping workspace membership would keep the admin short-circuit forever — visibleCollectionIDs returned nil (all access) based on the stale Role="admin", so events from collections outside the user's new collection_access="specific" scope would keep flowing. - computeSSEVisibility now re-fetches the user via s.store.GetUser before computing visibility. Transient DB errors fall back to the cached snapshot so a blip doesn't accidentally widen visibility. - The admin short-circuit (visibleIDs nil) now comes from the fresh user.Role, so demotion immediately trips the "no, actually filter" path on the next revalidation tick. Tests: - TestComputeSSEVisibility_DemotedAdminGetsFilter: set up a global admin who is a workspace member with collection_access="specific" and NO granted collections. Before demotion the admin gets nil (unrestricted). Demote to "member" → the snapshot must flip to a non-nil visibleSlugSet (system collections only). The cached-role bug would keep returning nil here. Parent: PLAN-643 (OSS Security Hardening).	2026-04-22 13:30:20 -04:00
xarmian	7ef4506cfa	fix: replace scattered tab-resume refetches with layered sync system ... When the browser tab lost focus and regained it, 5 independent onTabResume callbacks all fired simultaneously, flooding the server with redundant requests. This replaces that pattern with a 4-layer sync architecture: 1. Replay buffer — per-workspace ring buffer stores recent events with monotonic IDs. On SSE reconnect, missed events are replayed via Last-Event-ID so the client is already caught up. 2. Last-Event-ID support — SSE handler reads the header, replays from buffer, or sends sync_required if the gap is too large. 3. Incremental sync — new /changes?since=<ms> endpoint returns only modified/deleted items since a timestamp, including archived items for view consistency. 4. Centralized sync coordinator — single decision tree replaces 5 scattered callbacks. Short absences skip sync entirely, SSE-covered gaps need no API calls, and full refresh is a last resort. Key robustness details: - Global event IDs via Redis INCR for multi-instance safety - Server-time cursors to avoid client clock skew - Safe cursor management (only advances on confirmed sync) - 9 new tests for replay buffer and event ID behavior Fixes BUG-26.	2026-04-10 04:15:43 +00:00
xarmian	998716ae49	feat: unified item timeline with comment-on-update, threading, and reactions (#54) ... * feat: unified item timeline with comment-on-update, threading, and reactions (IDEA-115) Replace the separate Comments section and Version History modal on the item detail page with a single chronological timeline that interleaves comments, activities, and content versions. Key changes: - Add --comment flag to `pad item update` so agents/users can explain status changes inline (creates a comment linked to the activity) - Add threaded replies (parent_id on comments) with inline reply UI - Add emoji reactions on comments (new comment_reactions table) - New /timeline API endpoint merges comments, activities, and versions server-side with dedup and collapsing of rapid edits - New Svelte timeline components: ItemTimeline, TimelineCommentCard, TimelineActivityCard, TimelineVersionCard, ReactionPicker - Remove Implementation Notes and Decision Log inputs from web UI - Update skill docs to encourage --comment on status changes * fix: address review findings for PR #54 (iteration 1) - Use ListItemVersions instead of ListVersions in timeline endpoint so item content history renders correctly - Add workspace validation to reply and reaction handlers to prevent cross-workspace comment mutation - Raise activity cap from 500 to 10000 to avoid silently truncating long timelines - Fix toggleReaction to always POST (idempotent) instead of incorrectly matching other users' reactions for DELETE - Await onReply promise before clearing draft to prevent duplicate submissions and lost drafts on failure - Register reaction_added/reaction_removed in SSE ITEM_EVENTS so reactions from other sessions appear in real-time Co-Authored-By: Claude <noreply@anthropic.com> * fix: address review findings for PR #54 (iteration 2) - Fix nil pointer dereference in timeline handler when item not found - Store empty string instead of NULL for reaction user_id so UNIQUE constraint works correctly in SQLite - Add workspace validation to handleDeleteComment (cross-workspace deletion was possible) - Fix SKILL.md duplicate numbering (4. appeared twice) - Remove || true debug artifacts from reaction conditionals - Replace SvelteMap with plain Map in non-reactive groupReactions - Use != null checks for timeline API params to handle offset=0 - Log warning on comment creation failure during item update Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-04-03 07:25:56 -04:00
xarmian	d94a28c3e8	feat: account settings, email infrastructure, and UX polish (#23) ... - Add Account tab to settings: profile editing, password change, API token management - Add PATCH /api/v1/auth/me endpoint for profile updates with password verification - Add email sending infrastructure via Maileroo with contextual sender names - Add Platform settings tab (admin-only) for email configuration with test send - Add platform_settings table for instance-wide configuration - Add tab visibility refresh: silently sync data when browser tab regains focus - Fix filters icon: replace broken Unicode character with proper SVG funnel - Add cancel invitation support, TypeScript User/APIToken types	2026-03-29 18:29:52 -04:00
xarmian	4003772538	feat: show user names in activity feeds and real-time events (#17) ... Activity entries now display the authenticated user's name instead of generic "user"/"You" labels. The user_id (already present in the activities table from migration 012) is persisted when logging activity and joined against the users table when querying, so actor_name flows through the API without extra lookups. Falls back to the actor field value when no user is associated (e.g. pre-auth activities or deleted users). Backend: - Activity model gains UserID and ActorName fields - Store queries LEFT JOIN users to populate actor_name - logActivityWithMeta now records currentUserID on every activity - Dashboard API includes actor_name in recent_activity - SSE Event struct carries ActorName for real-time toasts - Item-level activity endpoint added (GET /items/{slug}/activity) Frontend: - Activity page shows user name badge (green) instead of "web" - Dashboard recent activity shows user name inline - ActivityFeed component displays user name instead of "You" - SSE toast notifications show user name instead of "CLI"	2026-03-28 19:11:42 -04:00
xarmian	81579847c6	Initial release ... Pad — project management for developers and AI agents. Single Go binary with embedded SvelteKit web UI, SQLite storage, CLI, and Claude Code /pad skill integration. https://getpad.dev	2026-03-26 01:52:36 +00:00