Datastore lock not released when interactive command fails in non-TTY context
Opened by swampadmin · 8/17/2025
Description
When swamp model search is run in a non-TTY context (e.g. from an AI agent or script), it acquires the datastore lock, then crashes because Ink's interactive UI requires raw mode on stdin. The lock file (.swamp/.datastore.lock) is never released, blocking all subsequent swamp CLI commands until the lock times out or is manually removed.
Steps to Reproduce
- Run
swamp model search <query>from a non-TTY context (e.g. piped stdin, or from an AI coding agent's shell tool) - The command crashes with:
Raw mode is not supported on the current process.stdin - Run any other swamp command (e.g.
swamp model search <query> --json) - The second command hangs and eventually fails with:
Lock ".swamp/.datastore.lock" held by <user> (pid <old_pid>) — timed out after 60194ms
Expected Behavior
- The datastore lock should be released in a
finallyblock (or equivalent cleanup) so that a crash in the interactive UI layer does not leave a stale lock behind. - Alternatively, interactive commands should detect non-TTY stdin early (before acquiring the lock) and either fall back to
--jsonoutput or fail with a clear error message.
Actual Behavior
The lock is acquired before the Ink UI is initialized. When Ink crashes due to missing raw mode support, the process exits without releasing the lock. Subsequent commands are blocked for ~60 seconds until the lock times out.
Environment
- swamp version: 20260310.230813.0-sha.fcc69c53
- OS: macOS (Darwin 25.3.0)
- Shell: zsh
- Context: Claude Code CLI (non-interactive shell)
Error Output
ERROR Raw mode is not supported on the current process.stdin, which Ink uses
as input stream by default.Followed by (on next command):
{
"error": "Lock ".swamp/.datastore.lock" held by user@host (pid 39643) — timed out after 60194ms"
}Summary
This bug affects the CLI lifecycle management around the datastore lock. The fix would involve ensuring lock release happens in a cleanup/finally path that runs even when the interactive rendering layer crashes. A secondary improvement would be to detect non-TTY stdin before launching interactive UI components and either fall back gracefully or fail fast with a descriptive error.
Closed
No activity in this phase yet.
Sign in to post a ripple.