fix: harden slash-command push and tasks-index sync against transient failures

[william0wang]

Root cause

Two unrelated intermittent bugs reported by the user.

Bug 1: slash commands occasionally not shown

sendAvailableCommandsDeferred fired available_commands_update exactly once after setTimeout(50ms). Zed initialises the session view on NewSessionResponse; if the view wasn't ready by the 50ms mark, the notification was dropped and the / completion menu stayed empty. session/resume and session/load go through the same deferred path. The "restart fixes it" symptom matches: the second session/new hits a warmed-up client where 50ms is enough.

Bug 2: sessions intermittently fail to sync to the ZCode App UI

newSession's upsertSessionTask is fire-and-forget (void, not awaited). The App's Electron host also writes to tasks-index.sqlite, so contended writes can surface as SQLITE_BUSY even with the 5s timeout — and the failure was swallowed by a quiet log() (only visible under ZCODE_ACP_DEBUG=1), making it look random.

Fix

src/handlers/io.ts

sendAvailableCommandsDeferred now fires the notification three times (50ms / 300ms / 1000ms) instead of once. available_commands_update is overwrite-semantics (not additive), so repeats are harmless — the client keeps the latest snapshot. Each timer is still unref()'d. Failures are now warn()'d instead of silently swallowed.

src/tasks-index.ts

upsertSessionTask wraps the write in a busy-retry loop (up to 3 attempts, 200ms / 400ms backoff). isBusyError matches "busy" / "locked" in the error message (covers SQLITE_BUSY code 5 and SQLITE_LOCKED code 6 without reaching into unstable error-code properties). Terminal failure is now warn()'d (user-perceivable — the session is invisible in the App UI) rather than hidden behind ZCODE_ACP_DEBUG. updateSessionTitle's catch is upgraded to warn() for the same reason.

All retries are self-contained inside tasks-index.ts; the void upsertSessionTask(...) call site in session.ts is unchanged.

Tests

tests/tasks-index.test.ts gains 2 cases (10 → 12):

• retries on SQLITE_BUSY and writes once contention clears — fake DB throws busy twice, then succeeds; asserts the row is written.
• gives up and returns false when busy persists past retries — all attempts busy; asserts false return, no row, and the skipped message surfaces on stderr.

Verification

• pnpm typecheck ✅
• pnpm test ✅ 274/274 passed
• pnpm lint ✅ 0 errors (remaining warnings are pre-existing sort-imports)
• pnpm prettier --write on the 3 changed files ✅

Out of scope

session/fork (src/index.ts:133) also misses both sendAvailableCommandsDeferred and upsertSessionTask. Per the user's report it's a secondary path, so left untouched in this PR — easy 5-line follow-up if needed.

[gemini-code-assist]

Code Review

This pull request introduces retry logic for SQLite operations in tasks-index.ts to handle database contention (SQLITE_BUSY/SQLITE_LOCKED) and updates sendAvailableCommandsDeferred to send multiple deferred notifications to accommodate slow client warm-up. The review feedback highlights a potential race condition in the deferred notifications that could overwrite newer commands, which can be resolved by tracking and clearing active timeouts. Additionally, the reviewer suggests refining the SQLite busy error detection regex to avoid false positives on file paths, and extracting a shared withRetry helper to deduplicate and apply retry logic consistently across both task upserts and session title updates.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[william0wang]

Thanks @gemini-codeassist for the review — all four points addressed in commit 3b5da72:

1. io.ts race condition (high) — Fixed. Added a module-level Map<sessionId, Set<timeout>> (activeDeferredTimeouts) that tracks pending timers per session. Each new sendAvailableCommandsDeferred call clears any still-pending timers for that session before scheduling its own, so a stale command list can't overwrite a newer one. Entry is cleaned up once all three fires settle.

2. updateSessionTitle retry (high) — Fixed. Refactored both upsertSessionTask and updateSessionTitle to go through a shared withSqliteRetry helper. Title updates now get the same busy-retry treatment as upserts. Added a regression test (retries on SQLITE_BUSY and updates the title once contention clears).

3. isBusyError regex specificity (medium) — Fixed. Tightened to /database is (busy|locked)/i. Verified the exact message format against a real node:sqlite v22 throw:

   Error: database is locked
   code: ERR_SQLITE_ERROR
   

   The original /\b(busy|locked)\b/i would have false-positive matched paths like /Users/busy_bee/.

4. withRetry helper extraction (medium) — Done as withSqliteRetry. Connection lifecycle is encapsulated, so both callers stay readable. One addition over the suggested shape: new Sqlite(...) is now inside the try block (with con declared outside so finally can close it), because SQLITE_BUSY can surface at connection-open time, not just during prepare/run — the original placement would have escaped the catch.

All checks pass: pnpm typecheck, pnpm test (275/275), pnpm lint (0 errors).