[bug] JSONL appendLines rollback can be skipped when handle.close() throws → duplicate seqs → session permanently unloadable

[JZQiang]

Summary

In appendLines, the partial-write rollback is gated behind closing the append handle. If handle.close() throws (common on real disk failures — ENOSPC/EIO), rollbackAppend never runs, partial bytes stay in the log, the retry re-appends the same sequence numbers, and the session becomes permanently unloadable.

Evidence

packages/session/session-persistence-jsonl/src/index.ts:651-679:

/**
 * Append and fsync event lines. On a partial write or sync failure, restore the
 * previous size before rethrowing because the unchanged cursor will retry the
 * batch; leaving partial bytes would create duplicate sequence numbers.
 */
private async appendLines(meta: SessionHeader, events: readonly SessionEvent[]): Promise<void> {
  const content = await this.encodeEventBatch(events)
  const path = logPath(this.root, meta.cwd, meta.id, this.compression)
  const handle = await open(path, 'a')
  let closed = false
  const closeAppendHandle = async (): Promise<void> => {
    if (closed) return
    closed = true
    await handle.close()
  }

  try {
    const { size: before } = await handle.stat()
    try {
      await handle.writeFile(content)
      await handle.sync()
    } catch (error) {
      try {
        await closeAppendHandle()          // ← closes FIRST
        await this.rollbackAppend(path, before)   // ← rollback never runs if close throws
      } catch (rollbackError) {
        throw new AggregateError([error, rollbackError], `failed to roll back append to "${path}"`)
      }
      throw error
    }
  } finally {
    await closeAppendHandle()
  }
}

The comment itself states the failure mode: "leaving partial bytes would create duplicate sequence numbers." The rollback (truncate(before) + fsync, rollbackAppend at 681-689) is scheduled after closeAppendHandle(). When the write/sync fails due to a disk fault, close() frequently fails too (same fault). Then:

1. Partial bytes remain at the tail.
2. SessionWriteBehind.startWrite (write-behind.ts:145-152) re-queues the same batch and retries.
3. The second append writes events with the same sequence numbers again.
4. SessionLogScanner.consumeEventLine (format.ts:364-371) rejects non-contiguous seq in the committed region → wrapped as SessionPersistenceCorruptionError (coordinator.ts:926-929) → the whole session cannot be loaded (verified: a duplicate-seq log is rejected by the scanner).

Rollback and close are two independent cleanup actions; one failing must not block the other.

Trigger

Append-time disk error + handle-close failure (low probability, but the consequence is whole-session corruption rather than a lost batch).

Suggested fix

Run rollbackAppend before closing the handle; merge both errors via AggregateError — the rollback must never be skipped because the close failed. (Note the outer finally still closes the handle, so closing early is redundant anyway.)

---

Verified at master 47f9438; duplicate-seq rejection by the scanner was reproduced locally with Node v22.