What
ak x verify aqe reports AQE startup as failed whenever another AQE process — normally the AQE MCP server running inside a Claude Code session — holds the patterns.rvf lock. AQE is healthy; it is only busy.
Cause is upstream. On a confirmed live lock, agentic-qe 3.14.3 (dist/integrations/ruvector/shared-rvf-adapter.js) logs the busy-owner warning, then falls through to a create attempt, which fails and surfaces a misleading FsyncFailed (0x0303). Store and lock bytes are unchanged (verified with a fixture: sha256 identical before/after). The emitted sequence is:
[RVF] <path> is locked by a live process (pid N) — not breaking the lock; degrading to SQLite for this run.
[RVF] <path> is unusable but its lock is held by a live process — leaving it alone…
[RVF] Shared adapter init failed: RVF error 0x0303: FsyncFailed
classifyAqeStartup() in src/lib/aqe-readiness.mjs deliberately tests FsyncFailed|0x0303 before the live-lock pattern (so a lock cannot hide an independent storage error), so this contention is classified failed and aqeVerificationPassed() returns false.
Upstream:
Found while verifying #237 (reported with a local dist/ patch to AQE, which upgrades overwrite). Related: #239.
Temporary kit mitigation (planned)
Recognize only the exact three-line contention fingerprint above as busy, keyed on the middle line ("is unusable but its lock is held by a live process"), which AQE emits only from its live-owner branch. A bare FsyncFailed, or lock + FsyncFailed without that middle line, stays failed. The busy reason stays honest: another AQE process holds the store; RVF integrity was not re-checked.
Where the temporary code will live
src/lib/aqe-readiness.mjs — the contention rule in classifyAqeStartup(), commented TEMPORARY (remove once fixed upstream) citing agentic-qe#574 / #719
tests/kit/aqe-verification.test.mjs — the captured three-line stderr → busy case
Exit criteria (close this issue when all true)
🤖 Generated with Claude Code
What
ak x verify aqereports AQE startup as failed whenever another AQE process — normally the AQE MCP server running inside a Claude Code session — holds thepatterns.rvflock. AQE is healthy; it is only busy.Cause is upstream. On a confirmed live lock, agentic-qe 3.14.3 (
dist/integrations/ruvector/shared-rvf-adapter.js) logs the busy-owner warning, then falls through to a create attempt, which fails and surfaces a misleadingFsyncFailed(0x0303). Store and lock bytes are unchanged (verified with a fixture: sha256 identical before/after). The emitted sequence is:classifyAqeStartup()insrc/lib/aqe-readiness.mjsdeliberately testsFsyncFailed|0x0303before the live-lock pattern (so a lock cannot hide an independent storage error), so this contention is classifiedfailedandaqeVerificationPassed()returns false.Upstream:
LockHeldinstead ofFsyncFailedand skips quarantine onLockHeld. Note: as read on 2026-09-26 it still attempts the create after the live-lock warning; onceFsyncFailedis gone, the kit's existing live-lock rule already yieldsbusy.Found while verifying #237 (reported with a local
dist/patch to AQE, which upgrades overwrite). Related: #239.Temporary kit mitigation (planned)
Recognize only the exact three-line contention fingerprint above as
busy, keyed on the middle line ("is unusable but its lock is held by a live process"), which AQE emits only from its live-owner branch. A bareFsyncFailed, or lock +FsyncFailedwithout that middle line, staysfailed. Thebusyreason stays honest: another AQE process holds the store; RVF integrity was not re-checked.Where the temporary code will live
src/lib/aqe-readiness.mjs— the contention rule inclassifyAqeStartup(), commentedTEMPORARY (remove once fixed upstream)citing agentic-qe#574 / #719tests/kit/aqe-verification.test.mjs— the captured three-line stderr →busycaseExit criteria (close this issue when all true)
patterns.rvf,aqe statusno longer emitsFsyncFailed, andak x verify aqereports startupbusythrough the pre-existing live-lock rule🤖 Generated with Claude Code