cross-process session write lease
跨进程会话写租约
The JSONL backend's write-handle claim excluded a second writer only inside one backend instance. Two processes — two CLI sessions, or a host beside an SDK runtime — could write-open the same session and interleave appends into one log file, tearing compressed frames and seq contiguity. The seam needed durable cross-process write ownership whose arbiter lives outside every writer process, because no writer outlives e
English
Problem
The JSONL backend's write-handle claim excluded a second writer only inside one backend instance. Two processes — two CLI sessions, or a host beside an SDK runtime — could write-open the same session and interleave appends into one log file, tearing compressed frames and seq contiguity. The seam needed durable cross-process write ownership whose arbiter lives outside every writer process, because no writer outlives every failure mode.
Decision
SessionWriteLease (packages/session/session-persistence-jsonl/src/lease.ts) holds a kernel lock on session.lock beside the log for the whole life of a write handle: POSIX takes a non-blocking flock(2) through the prebuilt @deepseek-ai/node-addon-system/flock binding, and Windows holds a named kernel semaphore (count 1) derived from the canonical lock path (CreateSemaphoreW in src/win32.ts beside the existing koffi bindings) — a kernel object with no filesystem footprint, destroyed with its last handle. Contention maps to SessionAlreadyOwnedError; the kernel releases the lock when the holder's descriptor or handle closes, including on any process death, so a crashed holder never blocks a successor and no expiry bookkeeping exists. A live but wedged holder keeps the lock until its process exits: expropriating a stalled writer was rejected because its resumed appends would tear the log, and on POSIX removing the lock file remains the explicit forfeit for that case. Because a POSIX lock names an inode rather than a path, acquisition verifies the locked inode is still the file at the lock path and retries otherwise. The lock is taken at write-open of an existing artifact and, for a created session, only right before its first materializing write — an unmaterialized session leaves no filesystem footprint, and a handle that acquired the lock keeps it through close even when materialization fails; release never removes the lock file, preserving the stable inode later lockers verify against. The browser worker deployment stubs the flock entry to immediate success because its in-process write claim excludes every writer. Its node:fs replacement still reports BigInt device and inode identity from FileHandle.stat({ bigint: true }), matching path stat while the path names that file, because the lease retains the inode-replacement check after the stubbed acquisition.
Alternatives considered
TTL record with renewal and claim-by-rename (implemented first, replaced in review) — a JSON record beside the log carrying an owner token and expiry, renewed on an interval, taken over by atomic rename after expiry. It survives every filesystem but is a distributed algorithm in miniature: renewal timers, loss detection, takeover claiming with re-judgment and give-back — and its residual multi-actor races still allowed bounded dual-writer overlap (one renewal interval). Kernel arbitration deletes the whole family plus the machinery, at the cost of a native build dependency and the wedged-holder semantics above.
proper-lockfile — the npm ecosystem's staleness-plus-touch implementation of the same TTL model. It retains the delete-then-recreate takeover race, detects compromise by mtime and inode (weaker than an owner token), and has had no release since 2021.
fs-ext's own Windows face (LockFileEx byte-range locks) — rejected after CI proof: Windows byte-range locks are mandatory, so any reader touching the locked file hard-fails (ripgrep died with os error 33 walking a session directory).
Windows exclusive-open sharing mode (CreateFileW denying FILE_SHARE_WRITE) — leaves readers untouched but pins the lock file's name and directory while held: CI showed dozens of suites failing their temp-root cleanup with EBUSY because a still-open handle blocks recursive removal, and users deleting a session directory would hit the same wall. The named semaphore keeps kernel arbitration with zero filesystem footprint.
Hand-rolled ffi for POSIX too (flock(2) via koffi) — binding selection and asynchronous errno handling are governed by the prebuilt system primitives decision. The Windows side retains the koffi bindings win32.ts already owns.
Consequences
Cross-process exclusion requires the platform's prebuilt system binding, one lock file per materialized session that release deliberately leaves in place, and the wedged-holder rule: a stuck process blocks that session's writers until it exits. It buys immediate crash recovery (no waiting period), no renewal traffic, and the removal of every takeover race the TTL design managed rather than prevented. Advisory flock is unreliable on some network filesystems (NFSv3); a root on such a mount degrades toward in-process-only exclusion. Deleting a live session's lock file forfeits exclusion on POSIX by design — the harness never does so; the agent-loop resume test uses it deliberately to simulate a wedged first lifecycle, and skips on Windows, where the lock is a kernel object no file operation can forfeit.
中文
Problem
JSONL 后端的写句柄认领只在单个后端实例内部排除第二个写入方。两个进程——两个 CLI 会话，或宿主与 SDK 运行时并存——可以对同一会话执行写打开，把追加交错写进同一个日志文件，撕坏压缩帧与 seq 连续性。该 seam 需要一份仲裁者位于所有写入进程之外的持久跨进程写所有权，因为没有任何写入方能活过所有故障模式。
Decision
SessionWriteLease（packages/session/session-persistence-jsonl/src/lease.ts）在日志旁的 session.lock 上持有内核锁，贯穿写句柄的整个生命期：POSIX 经由预编译 @deepseek-ai/node-addon-system/flock 绑定 以非阻塞 flock(2) 加锁，Windows 持有由规范锁路径派生的命名内核信号量（计数 1，CreateSemaphoreW，实现在 src/win32.ts 既有 koffi 绑定旁）——零文件系统足迹的内核对象，随最后一个句柄关闭而销毁。竞争映射为 SessionAlreadyOwnedError；持有者的描述符或句柄关闭时内核释放锁，包括任何形式的进程死亡，因此崩溃的持有者从不阻塞后继者，也不存在任何过期簿记。活着但卡死的持有者保有锁直到其进程退出：剥夺停顿写入方的所有权被否决，因为其复活后的追加会撕坏日志；POSIX 上删除锁文件仍是该场景的显式放弃手段。由于 POSIX 锁指向 inode 而非路径，获取后会校验所锁 inode 仍是锁路径上的文件，否则重试。锁在写打开既有工件时立即获取，新建会话则仅在首次物化写入之前获取——未物化的会话不留任何文件系统足迹，已取得锁的句柄即使物化失败也保有锁直到关闭；释放从不删除锁文件，保住后续加锁者用于校验的稳定 inode。浏览器 worker 部署将 flock 入口存根为立即成功，因为进程内写认领已排除所有写入方。它的 node:fs 替代实现仍从 FileHandle.stat({ bigint: true }) 报告 BigInt device 与 inode 身份，并在该路径仍指向所打开文件时与路径 stat 一致，因为租约在存根式加锁后仍保留 inode 替换检查。
Alternatives considered
TTL 记录加续约与 rename 认领（最初实现，review 中被替换） —— 日志旁的 JSON 记录携带 owner 令牌与过期时间，按间隔续约，过期后以原子 rename 接管。它在所有文件系统上都能活，但本质是一个微缩的分布式算法：续约定时器、丢失检测、带复核与归还的接管认领——而其残余的多方竞态仍允许有界的双写重叠（一个续约间隔）。内核仲裁删除了整族竞态及其全部机制，代价是一个原生构建依赖和上述卡死持有者语义。
proper-lockfile —— npm 生态对同一 TTL 模型的"过期判定加 touch"实现。它保留"先删后建"的接管竞态，用 mtime 加 inode 检测失主（弱于 owner 令牌），且自 2021 年起再无发布。
fs-ext 自带的 Windows 实现（LockFileEx 字节区间锁） —— 被 CI 实证否决：Windows 的字节区间锁是强制锁，任何读到被锁文件的进程都会硬失败（ripgrep 遍历会话目录时以 os error 33 崩掉）。
Windows 共享模式独占打开（CreateFileW 拒绝 FILE_SHARE_WRITE） —— 读者不受影响，但持有期间钉住锁文件的名字与目录：CI 显示数十个套件的临时根清理因仍打开的句柄阻塞递归删除而报 EBUSY，用户删除会话目录也会撞上同一堵墙。命名信号量保住内核仲裁，且文件系统足迹为零。
POSIX 也手写 ffi（经 koffi 调 flock(2)） —— 绑定选择与异步 errno 处理由预编译系统原语决策规定。Windows 侧保留 win32.ts 已有的 koffi 绑定。
Consequences
跨进程排他需要对应平台的预编译系统绑定、每个物化会话一个由释放刻意留下的锁文件，以及卡死持有者规则：卡住的进程阻塞该会话的写入方直到其退出。它换来的是即时崩溃恢复（无等待期）、零续约流量，以及删除了 TTL 设计只能"管理"而非"消除"的全部接管竞态。咨询式 flock 在部分网络文件系统（NFSv3）上不可靠；位于此类挂载上的根目录会退化为仅进程内排他。POSIX 上删除活跃会话的锁文件按设计即放弃排他——harness 自身从不这样做；agent-loop 的 resume 测试刻意用它模拟卡死的第一个生命周期，并在 Windows 上跳过：那里的锁是任何文件操作都无法放弃的内核对象。