Notes: online warm open retains a deleted body after the live room refuses it #829

Open
opened 2026-10-02 13:21:00 +00:00 by kayg · 0 comments
Owner

Independent round 7b review for #427. Branch job/perf-cache-665, head b88bc6ac88. Non-blocking: stale deleted Note display and unusable fallback editing; no accepted server write was shown.

Context: a User caches a Note, disconnects, and misses its deletion event. The User returns online and opens its stable link.

Evidence:

  • apps/web/src/lib/notes/NoteView.svelte:150-160: a cached body immediately sets phase to ready.
  • NoteView.svelte:182: cached ?? getNote skips the authoritative read on a warm open.
  • NoteView.svelte:319-328: an unsynced room refusal clears cachedWarm, enables fallback editing, and destroys the provider. It does not invalidate the body, read the Note again, or show the missing state.
  • apps/web/src/lib/notes/collab.ts:213-218: missing/denied/unsupported room upgrades share the refused status after retries. The view cannot assume that refusal means a valid Note without live support.

Reproduction: run the actual load and connect function bodies from the branch with an online cached Note and a provider fixture; deliver refused before sync. The resulting state remains ready, retains the old body, enables fallback, and performs zero getNote reads. The fixture does not run the Svelte renderer or a real WebSocket server. Offline retained bodies are intentional; this finding is about an online authoritative refusal.

Expected: invalidate and revalidate on refusal. For an authoritative missing response, clear the retained body and render the missing state. A valid Note can still use fallback editing after an authorized read confirms it exists.

Regression test idea: warm a Note, close the event connection, delete it through a second client, then return online and open its link. Refuse the room and assert an authoritative read followed by the missing state, with no editable deleted body.

Duplicate check: searched all issue titles and deleted/refusal/warm-cache terms, including #600, #623, #639 and #665. No separate missed-deletion warm-open refusal issue was found.

Independent round 7b review for #427. Branch job/perf-cache-665, head b88bc6ac888fd18e7e8a256f0b5b65ecaeed92c2. Non-blocking: stale deleted Note display and unusable fallback editing; no accepted server write was shown. Context: a User caches a Note, disconnects, and misses its deletion event. The User returns online and opens its stable link. Evidence: - apps/web/src/lib/notes/NoteView.svelte:150-160: a cached body immediately sets phase to ready. - NoteView.svelte:182: cached ?? getNote skips the authoritative read on a warm open. - NoteView.svelte:319-328: an unsynced room refusal clears cachedWarm, enables fallback editing, and destroys the provider. It does not invalidate the body, read the Note again, or show the missing state. - apps/web/src/lib/notes/collab.ts:213-218: missing/denied/unsupported room upgrades share the refused status after retries. The view cannot assume that refusal means a valid Note without live support. Reproduction: run the actual load and connect function bodies from the branch with an online cached Note and a provider fixture; deliver refused before sync. The resulting state remains ready, retains the old body, enables fallback, and performs zero getNote reads. The fixture does not run the Svelte renderer or a real WebSocket server. Offline retained bodies are intentional; this finding is about an online authoritative refusal. Expected: invalidate and revalidate on refusal. For an authoritative missing response, clear the retained body and render the missing state. A valid Note can still use fallback editing after an authorized read confirms it exists. Regression test idea: warm a Note, close the event connection, delete it through a second client, then return online and open its link. Refuse the room and assert an authoritative read followed by the missing state, with no editable deleted body. Duplicate check: searched all issue titles and deleted/refusal/warm-cache terms, including #600, #623, #639 and #665. No separate missed-deletion warm-open refusal issue was found.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#829
No description provided.