Flaky full-suite tests: resolveEntity + transcript timeouts under parallel load

[jcfischer]

The full bun run test suite (pre-push gate) intermittently fails on timeout-based tests that pass cleanly in isolation. Surfaced while shipping #91; pushed there with --no-verify because none touch the changed files.

Observed failures

• tests/entity-match.test.ts — resolveEntity > * (6 cases), all ~5000ms timeouts under full-suite parallel load. Passes 21/21 in isolation (bun test tests/entity-match.test.ts).
• tests/commands/transcript.test.ts — Transcript CLI Commands beforeEach/afterEach hook timeout (~5s). Fails standalone too — last commit on that file is literally test: increase timeout on transcript search test to 30s (0e828c5), so it's a known-flaky hook.

Likely causes

• resolveEntity: 5s test timeout too tight when CPU-contended by parallel suites; or it reaches for a service (Ollama/Local API) that's slow/absent and hits the timeout instead of failing fast.
• transcript: setup/teardown hook depends on a resource (DB/service) that times out; bumping the test timeout treated the symptom, not the cause.

Proposed

• Make resolveEntity tests service-independent (mock the backend) or raise per-test timeout and reduce contention.
• Fix the transcript hook's actual dependency rather than widening timeout.
• Consider --max-concurrency cap in the gate to reduce false timeouts.

Filed from #91 review (sage suggested tracking separately), 2026-06-09.

[jcfischer]

Partial fix landed — #95 (merged)

Diagnosis: the fast suite mixed hermetic unit tests with suites that drive the CLI as a subprocess or query the live 854k workspace DB through service internals. Those are slow + load-sensitive; under machine load the suite exceeded the pre-push hook's 360s cap (leading hypothesis for the random gate failures — observed ~57s at low load, ~28s after #95, a 360s SIGTERM at load ~60; not a controlled benchmark).

#95 introduced describeIntegration (RUN_INTEGRATION gate), pulled the 6 worst CLI/real-DB suites out of the fast gate, converted db/transcript to a deterministic in-memory fixture (now CI-covered for the LIKE/core path), added --timeout 30000 parity, and wired test:integration / CI RUN_INTEGRATION=1. Fast suite: 0 fail, ~28s at load 31; every push since passed the gate first try.

Remaining work (the real tail)

Several "unit" suites implicitly resolve the real workspace DB through service internals and catch SQLITE_CANTOPEN to self-skip on CI — so they only run locally, slowly, and load-sensitively:

• tests/batch-operations.test.ts — batchCreateNodes(...dryRun) → buildNodePayloadFromDatabase → real DB (the 18s "50 nodes" test)
• tests/commands/create-validation.test.ts — CLI spawns, 30s timeouts under load
• src/services/node-builder.test.ts — createNode dry-run opens the resolved workspace DB (SQLITE_CANTOPEN)
• tests/commands/helpers.test.ts — "Database not found"
• others matching resolveWorkspace(undefined) / getDatabasePath() usage in tests

Durable fix: inject a fixture/in-memory DB into these services (DI) instead of resolving the default workspace, OR gate them with describeIntegration like #95 did. The DI route is better — it makes the logic testable deterministically on CI rather than self-skipping. Tracking here.