Problem
A Space library keeps showing a page after the same owner deletes it in another browser tab. Successful later polls already omit the deleted page, but mergePageSnapshot keeps every previously known row forever unless this particular component issued the deletion itself.
This is an ordinary single-owner, two-tab workflow, not a request for multi-user collaboration or a recycle bin.
Reproduction
- Open the same Space in tabs A and B, with a saved page visible in both.
- Keep A on the page library. In B, open the page and use Page actions → Delete page.
- Wait for A's regular page-list polling to complete successfully more than once.
- A still shows the deleted page even though
GET /api/spaces/:spaceId/pages omits it and the page API returns 404.
Expected: a successful fresh complete list should remove the deleted library row. If that page is open for editing in A, keep its local draft available and explain the external deletion rather than silently unmounting the editor.
Actual: the deleted row remains until the Space component is remounted/reloaded; opening or saving it produces a not-found error.
Verification
- Upstream
main at 625452e, Node.js 24.16.0, Chrome on macOS.
- Reproduced with two actual browser pages using the real
SpaceWorkspace, SpaceLibrary, PageDocument, ReactDOM StrictMode, repository CSS, and the project's real Hono page API / SQLite store with synthetic in-memory data.
- After B deleted a parent, its child was correctly reparented on the server. A completed two further list polls, but still displayed one deleted-parent row.
- No Intelligence/model/Slack/voice credentials or live cloud services were needed.
Fix boundaries
The existing union merge protects a newly created page from a list request that started before creation. A fix should preserve that protection, newer saved revisions, and local-deletion tombstones. It also needs to avoid older overlapping list responses resurrecting deleted rows and preserve an already-open unsaved draft.
I am preparing a bounded client fix with regression tests and browser checks. This is separate from #114's version-history/trash/import-export proposal: its polling path still uses the same union merge.
Problem
A Space library keeps showing a page after the same owner deletes it in another browser tab. Successful later polls already omit the deleted page, but
mergePageSnapshotkeeps every previously known row forever unless this particular component issued the deletion itself.This is an ordinary single-owner, two-tab workflow, not a request for multi-user collaboration or a recycle bin.
Reproduction
GET /api/spaces/:spaceId/pagesomits it and the page API returns 404.Expected: a successful fresh complete list should remove the deleted library row. If that page is open for editing in A, keep its local draft available and explain the external deletion rather than silently unmounting the editor.
Actual: the deleted row remains until the Space component is remounted/reloaded; opening or saving it produces a not-found error.
Verification
mainat625452e, Node.js 24.16.0, Chrome on macOS.SpaceWorkspace,SpaceLibrary,PageDocument, ReactDOM StrictMode, repository CSS, and the project's real Hono page API / SQLite store with synthetic in-memory data.Fix boundaries
The existing union merge protects a newly created page from a list request that started before creation. A fix should preserve that protection, newer saved revisions, and local-deletion tombstones. It also needs to avoid older overlapping list responses resurrecting deleted rows and preserve an already-open unsaved draft.
I am preparing a bounded client fix with regression tests and browser checks. This is separate from #114's version-history/trash/import-export proposal: its polling path still uses the same union merge.