A file the owner creates while a guest’s folder listing opens never reaches the guest #119

New issue

Closed

opened 2026-09-23 16:32:34 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-23 16:32:34 +01:00

Owner

Observed

CI run 531 (run #399, e2e.yml on worktree-gtm at 21bddd4), 23 September 2026, 15:21 UTC. In packages/e2e/test/multi/identity.test.ts, the test "signs in with an emailed code, accepts an invitation from inside Obsidian, and syncs with the owner" failed at identity.test.ts:868:

Timed out waiting for: the guest vault should receive the owner's note
  waiting vault contains: ["Shared/note.md"]
  Shared/from-owner.md currently: "null"

The next test ("unshares a folder…") failed only on that precondition.

What the logs show

The guest vault's diag log (all 9 lines):

15:21:46.800 Signed in.
46.833 Connected.
47.229 Background sync starting {"localPath":"Shared","files":1}.
47.274–47.782 Bound and synced Shared/note.md.
Nothing after that, until the timeout at 15:22:47.

On the server:

46.832 The guest's websocket connected.
46.835 Folder member added.
46.906 The guest ran GET /folders and GET /account.

The test creates Shared/from-owner.md in the owner vault immediately after the guest's refreshSync(). So the owner's file was created while the guest's folder listing was opening, and the guest never learned it existed.

Ruled out, and how

A port or display collision with the concurrent run. This run held its own port block (29280–29311), its Xvfb reported abstract X11 sockets: 0, and every request in the failing test reached this run's own servers. There was no EADDRINUSE or refused connection. The overlapping run (530, main) passed the same suite.
A known issue. None of the 29 failed e2e runs back to run 140 show this test failing. The earlier identity.test.ts failures (runs 296–347) were other tests.
The "file created before the folder's listing has opened" entry in docs/sync-limitations.md. That entry is about a local file, and it is fixed.

Not known

Whether the guest would ever have received the file. The test gives up at 60 s. If it never would, two vaults silently disagree with nothing visible. That is the failure mode CLAUDE.md ranks worst after loss.
Whether load exposed it. It is the first observation. The runner was at capacity 3 for the first time, with two e2e suites and main's two-platform image build running together.
Where the event goes missing. The server logs no listing broadcast at info level, so this log cannot say whether the create was sent before the guest subscribed, sent and dropped, or never sent.

To do

Instrument before theorising (CLAUDE.md): log, at debug level, the folder-listing subscribe on the guest, and each listing-change broadcast and delivery on the server, with the doc and member ids.
Reproduce deliberately: a guest joining while the owner creates a file, swept across a range of delays between the guest's refreshSync() and the owner's create. Wait long enough to answer "ever", not just "within 60 s".
Depending on what that shows: if the create can be lost, it is a defect in the snapshot/subscribe ordering. Fix it and move the sync-limitations.md entry to "fixed". If it only arrives late, record the bound.

Recorded as open in docs/sync-limitations.md and packages/e2e/README.md.

## Observed CI run 531 (run #399, `e2e.yml` on `worktree-gtm` at `21bddd4`), 23 September 2026, 15:21 UTC. In `packages/e2e/test/multi/identity.test.ts`, the test "signs in with an emailed code, accepts an invitation from inside Obsidian, and syncs with the owner" failed at `identity.test.ts:868`: ``` Timed out waiting for: the guest vault should receive the owner's note waiting vault contains: ["Shared/note.md"] Shared/from-owner.md currently: "null" ``` The next test ("unshares a folder…") failed only on that precondition. ## What the logs show The guest vault's diag log (all 9 lines): - **15:21:46.800** Signed in. - **46.833** Connected. - **47.229** `Background sync starting {"localPath":"Shared","files":1}`. - **47.274–47.782** Bound and synced `Shared/note.md`. - **Nothing after that**, until the timeout at 15:22:47. On the server: - **46.832** The guest's websocket connected. - **46.835** Folder member added. - **46.906** The guest ran `GET /folders` and `GET /account`. The test creates `Shared/from-owner.md` in the owner vault immediately after the guest's `refreshSync()`. So the owner's file was created while the guest's folder listing was opening, and the guest never learned it existed. ## Ruled out, and how - **A port or display collision with the concurrent run.** This run held its own port block (29280–29311), its Xvfb reported `abstract X11 sockets: 0`, and every request in the failing test reached this run's own servers. There was no `EADDRINUSE` or refused connection. The overlapping run (530, `main`) passed the same suite. - **A known issue.** None of the 29 failed e2e runs back to run 140 show this test failing. The earlier `identity.test.ts` failures (runs 296–347) were other tests. - **The "file created before the folder's listing has opened" entry in `docs/sync-limitations.md`.** That entry is about a **local** file, and it is fixed. ## Not known - **Whether the guest would *ever* have received the file.** The test gives up at 60 s. If it never would, two vaults silently disagree with nothing visible. That is the failure mode `CLAUDE.md` ranks worst after loss. - **Whether load exposed it.** It is the first observation. The runner was at capacity 3 for the first time, with two e2e suites and `main`'s two-platform image build running together. - **Where the event goes missing.** The server logs no listing broadcast at info level, so this log cannot say whether the create was sent before the guest subscribed, sent and dropped, or never sent. ## To do 1. **Instrument before theorising** (`CLAUDE.md`): log, at debug level, the folder-listing subscribe on the guest, and each listing-change broadcast and delivery on the server, with the doc and member ids. 2. **Reproduce deliberately**: a guest joining while the owner creates a file, swept across a range of delays between the guest's `refreshSync()` and the owner's create. Wait long enough to answer "ever", not just "within 60 s". 3. Depending on what that shows: if the create can be lost, it is a defect in the snapshot/subscribe ordering. Fix it and move the `sync-limitations.md` entry to "fixed". If it only arrives late, record the bound. Recorded as open in `docs/sync-limitations.md` and `packages/e2e/README.md`.

cruelacid added the

area:plugin

area:server

labels

2026-09-23 16:32:34 +01:00

cruelacid referenced this issue

2026-09-23 16:33:00 +01:00

Record a file that never reached a guest as an open sync limitation #120

cruelacid referenced this issue from a commit

2026-09-23 16:33:01 +01:00

Record a file that never reached a guest as an open sync limitation

cruelacid referenced this issue from a commit