fix(mcp): set SQLite busy_timeout so allowlist CLI works while the service runs #107

Merged

David merged 1 commit from fix/YT-49-sqlite-busy-timeout into main

2026-07-06 00:05:47 +02:00

David commented

2026-07-05 23:51:51 +02:00

Owner

What

Makes yt mcp allowlist reliable while yt mcp serve is running, and completes its documentation. Implements YT-49.

Why

db::open set no busy_timeout, so a yt mcp allowlist add/remove write while the service held a lock could fail immediately with database is locked. Both the service and the CLI open the same file via db::open, and the CLI's whole purpose is to edit the allowlist while the service runs (bootstrap / recovery), so this papercut defeated it.

Changes

db::open: add .busy_timeout(Duration::from_secs(5)) to the shared SqliteConnectOptions. A writer now waits up to 5s for the service's brief lock instead of erroring. No on-disk format change (WAL intentionally not enabled; deferred).
docs/deployment.md allowlist section: state the commands are safe to run live, describe the list output (login/email, when, by whom), and document add (idempotent) / remove (no-op when absent).

Scope note

The request was to bring the yt mcp allowlist docs up to date. Rather than document a "stop the service first" workaround, this includes the one-line busy_timeout fix so the docs can accurately say the commands are safe to run live.

Invariant sweep (every state-DB open gets the busy timeout)

Site	Classification
`db::open`	fixed: sets 5s busy_timeout
all consumers (`serve`, `yt mcp allowlist`, tests)	covered: all open through `db::open`; no other `SqlitePoolOptions::connect` exists in the crate

Tests

New open_sets_busy_timeout asserts PRAGMA busy_timeout is 5000 after db::open.
Existing db behavior (parent-dir creation, migrations, roundtrip) unchanged. Full just pre-commit green (89 tests).

Related: YT-47 (allowlist CLI), YT-45 (docs rewrite).

## What Makes `yt mcp allowlist` reliable while `yt mcp serve` is running, and completes its documentation. Implements YT-49. ## Why `db::open` set no `busy_timeout`, so a `yt mcp allowlist add/remove` write while the service held a lock could fail immediately with `database is locked`. Both the service and the CLI open the same file via `db::open`, and the CLI's whole purpose is to edit the allowlist while the service runs (bootstrap / recovery), so this papercut defeated it. ## Changes - `db::open`: add `.busy_timeout(Duration::from_secs(5))` to the shared `SqliteConnectOptions`. A writer now waits up to 5s for the service's brief lock instead of erroring. No on-disk format change (WAL intentionally not enabled; deferred). - `docs/deployment.md` allowlist section: state the commands are safe to run live, describe the `list` output (login/email, when, by whom), and document `add` (idempotent) / `remove` (no-op when absent). ## Scope note The request was to bring the `yt mcp allowlist` docs up to date. Rather than document a "stop the service first" workaround, this includes the one-line `busy_timeout` fix so the docs can accurately say the commands are safe to run live. ## Invariant sweep (every state-DB open gets the busy timeout) | Site | Classification | | --- | --- | | `db::open` | fixed: sets 5s busy_timeout | | all consumers (`serve`, `yt mcp allowlist`, tests) | covered: all open through `db::open`; no other `SqlitePoolOptions::connect` exists in the crate | ## Tests - New `open_sets_busy_timeout` asserts `PRAGMA busy_timeout` is 5000 after `db::open`. - Existing db behavior (parent-dir creation, migrations, roundtrip) unchanged. Full `just pre-commit` green (89 tests). Related: YT-47 (allowlist CLI), YT-45 (docs rewrite).

David added 1 commit

2026-07-05 23:51:51 +02:00

fix(mcp): set SQLite busy_timeout so allowlist CLI works while the service runs

Check / fmt + clippy + build + tests (pull_request) Successful in 1m1s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

61c717e2ba

`db::open` opened the state DB with no busy_timeout, so a `yt mcp allowlist` write while `yt mcp serve` held a lock could fail immediately with `database is locked`. Since the CLI exists precisely to edit the allowlist while the service runs (bootstrap / recovery), that forced operators to stop the service.

Set a 5s busy_timeout on the shared `db::open` options so a writer waits for the service's brief lock instead of erroring. Document in the allowlist section that the commands are safe to run live, and describe the list output and the add (idempotent) / remove (no-op when absent) semantics.

#YT-49

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>