Bug: JSONL session ownership is process-local, allowing concurrent writers

[antst]

Observed behavior

At commit 49a606bc (0.1.2-alpha.5), two DSH processes using the same JSONL persistence root can both resume the same session for writing. Neither process receives SessionAlreadyOwnedError.

Evidence

The persistence contract says that open(id, 'write') “atomically claims single-writer ownership” and rejects an active owner (packages/session/session-persistence/src/index.ts:149-160).

The JSONL implementation claims ownership in open() through tracker.claimWrite(id) (packages/session/session-persistence-jsonl/src/index.ts:215-256). That tracker stores writers in an instance-local Map, and claimWrite() checks only that map (packages/session/session-persistence-jsonl/src/storage.ts:319-361). A second process has a separate map and therefore accepts the same session.

The append path then opens the shared log in append mode (packages/session/session-persistence-jsonl/src/index.ts:838-866). Both writers can start from the same logical cursor and append overlapping sequence numbers, making the stored log ambiguous or invalid on its next read.

Minimal reproduction

1. Create and materialize a session, then stop its original owner.
2. Start two DSH processes whose JSONL persistence entries use the same root (use different listen addresses if running two Web profiles).
3. In both processes, resume the same persisted session id.
4. Submit work in each process before closing either session.

Expected: the second resume fails with SessionAlreadyOwnedError.

Actual: both resumes succeed and both processes append to the same session log.

Impact on plugin authors

A plugin or alternate UI cannot safely offer session resume when another DSH process may use the same persistence root. Adding a plugin-owned lock would duplicate persistence ownership and cannot cover other DSH clients.

Possible fix

The JSONL backend could hold an exclusive cross-process lock keyed by session id for each write handle, recording host/pid ownership for safe stale-owner recovery and releasing it from close().

[argszero]

Verified your full chain at master 49a606b (the exact commit you cite) — every line reference matches, and I can add the missing piece: the persistence contract over-promises. session-persistence/src/index.ts open() javadoc says: "write atomically claims single-writer ownership; an existing active owner rejects" — no process/instance scope qualifier anywhere. The JSONL implementation honors that only inside one process: storage.ts:329 writers = new Map<SessionId, …> (instance-local), claimWrite() :359-361 throws only on a Map hit, index.ts:243 calls it with no cross-process artifact behind it, and appendLines :838-866 is a blind open(path,'a') + write + sync.

This is not the first report of the mechanism — it is corruption-family mechanism #1. #1452 (2026-08-14, rc.6) reproduced it byte-for-byte: Web backend + desktop shell on the same DSH_HOME both appended to one session.jsonl.zstd; seqs 38422-38425 landed twice (identical lines), the loader refused with "seq gap in committed region". Root causes there still hold at alpha.5: seq is index-derived per Session instance (seq = log.length in the core session append), and the coordinator's per-id serialization is in-process only. Consequence shape: append-only means data is duplicated, not lost — the harm is the hard unloadable session + hand-repair, exactly your "ambiguous or invalid on its next read". #1333 is the sibling thread.

Your proposed fix already has a tested community implementation. wellorbetter's fork from #1550 (commit 159c5e4f6, branch fix/session-history-responsiveness) added writer-lease.ts: an atomic link()-based exclusive lock per session under a <root>/.dsh-jsonl-writer-locks/ directory (sha256-keyed, dir 0700), claimed in the append path (both appendLines and materialize branches) and in repair, released from close() after the coordinator drain; same-host stale-owner takeover via PID liveness + rename (no unlink race), foreign host fails closed. I fetched and ran its tests at the time — writer-lease 2/2, jsonl 152/152, zstd 81/81 green — and posted a design evaluation on #1550 (comment-18021537). That is the closest thing to the "cross-process lock keyed by session id + host/pid owner + release on close" you describe, and it was never merged upstream.

Two caveats worth carrying into any upstream fix:

1. A cross-process lease fixes the multi-process half only. The family also has same-process stale-view mechanisms (Bug: session log corrupted on resume - last 4 committed events re-appended with fresh timestamps (seq gap in committed region) #2167 re-append from a stale committed view, 会话日志在回合中断后因已提交 seq 回退而整条不可加载 #5103 two instances in one process) that a lease cannot catch — the complementary half is a durable tail assertion at the live-append boundary (first new seq must equal the durable committed length; refuse loudly, don't truncate).
2. Regardless of fix, the open() javadoc should be scoped ("within this service instance") until a lease lands — your impact paragraph is exactly why: plugin authors read the contract at face value.

Confirmed open upstream at alpha.5. Suggest upstream adopt the lease design (it is community-tested) or at minimum scope the contract and fail loud. Worth auditing sibling backends for the same pattern — SQLite's physical-collision guard was likewise reported per-process-only (#4264).