Repository navigation
supabase status spins at ~160% CPU forever when stdout and stderr share a pipe whose reader closes early #6846
Description
Activity
Reproduced on macOS 27.0 (26A428), Apple Silicon, Homebrew CLI 2.118.0 and 2.119.0. Given that it didn't reproduce on 26.6.2, the macOS version does look relevant.
Our trigger was
supabase db query --linked "..." 2>&1 | jq -c ..--linkedprintsInitialising login role...on stderr, jq stops withparse error: Invalid numeric literal at line 1, column 13, and the CLI keeps spinning at ~155% CPU. One run went unnoticed for 8 hours (12.5 h of CPU time).Measurements, each run killed by a watchdog after 20-25 s:
Command 2.118.0 2.119.0 db query --linked "select 1" 2>&1 | jq -c .hangs, 151.8% CPU hangs, 156.4% CPU db query --linked "select 1" 2>/dev/null | truehangs, 153.8% / 154.7% / 159.3% CPU (3 of 3 runs) db query --linked "select 1" 2>/dev/null | jq -c .exits 0 exits 0 db query --linked "select 1" 2>/dev/null | cat >/dev/nullexits 0 db query --linked "<3000 rows>" 2>/dev/null | head -c 100exits 0 projects listwith2>&1 | true,2>&1 >/dev/null | true,2>/dev/null | trueintermittent: 2 of the 3 hung in each of two runs; none hung in a third run, which added -o yaml/toml/jsonto tell the processes apartOne correction to the original report: stderr doesn't have to share the pipe. With
db query --linked, stdout alone hangs when the reader has already exited before the CLI's first write (| true). Withprojects listthe same variants hang only some of the time, so it looks timing-dependent.While the process was spinning,
lsofshowed no TCP socket left open (the query had finished): fds 1 and 2 were on the dead pipe.sampleshows the main thread looping throughkevent64,__ulock_wake,os_unfair_lock_lockandclock_gettime. The worker threads are namedBun Pool 0/1andHTTP Client.Full
sampleoutput of that 8-hour process (2.118.0), as requested: https://gist.github.com/yannf86/534758bafa5353fd3530e346271bac3bReacted by Vaibhav
Environment
supabase,@supabase/cli-darwin-arm64); also observed on 2.118.0supabase start)Steps to reproduce
npx supabase status 2>&1 | head -3Expected
headprints three lines and exits; the CLI receives EPIPE/SIGPIPE on its next write and exits.Actual
headexits, but the CLI process never does. It stays at 157-161% CPU until killed.sampleshows the main thread looping inkevent64. Because the shell waits on every member of a pipeline, the command never completes. One background invocation ran for 14 hours before it was noticed.Measurements (each run killed by a watchdog after 15-25 s)
npx supabase status 2>&1 | head -3npx supabase status 2>&1 | grep -q Stoppednode_modules/@supabase/cli-darwin-arm64/bin/supabase status 2>&1 | head -1npx supabase status 2>/dev/null | head -3npx supabase status 2>&1 >/dev/null | head -1npx supabase status 2>&1 | cat >/dev/nullX=$(npx supabase status -o json 2>/dev/null)The hang requires both stdout and stderr in the same pipe, with a reader that closes before the CLI has finished writing. Piping only one stream, or draining everything, exits normally. Setting
SUPABASE_NO_UPDATE_NOTIFIER=1does not change the result.Suggested fix
Exit (or stop writing) when a write to stdout or stderr fails with EPIPE, rather than retrying in the event loop.
Workaround
Capture the whole output first (
X=$(supabase status -o json 2>/dev/null)) or redirect to a file, then read that.