CLI stdin buffering can OOM long-running commands fed by yes

[JeetChakrabarty]

Summary

With Supabase CLI 2.114.0, running a long-lived command through an unbounded stdin producer can grow the CLI process until the kernel OOM-kills it.

Observed twice on a Linux ARM64 CI runner during db push:

• attempt 1: about 5,172,380 KB anonymous RSS
• attempt 2: about 5,187,744 KB anonymous RSS
• both processes were killed by the kernel while supabase db push was still running

The migration input was small (about 325 KB total), and a separately generated rollback artifact had already completed at about 66 KB. Removing the pipe and using the global --yes flag avoids the growth.

Invocation that exhibited the issue

yes | PGOPTIONS="--search_path=public,extensions" \
  supabase db push --linked --include-all --password "$DB_PASSWORD"

Working invocation

PGOPTIONS="--search_path=public,extensions" \
  supabase --yes db push --linked --include-all --password "$DB_PASSWORD"

Suspected boundary

The TypeScript stdin layer appears to retain unread piped lines while the command is occupied with the migration. An infinite yes stream can therefore accumulate even though the command needs only bounded confirmation input.

Reference: apps/cli/src/shared/runtime/stdin.layer.ts at tag v2.114.0.

Suggested behavior

Either apply backpressure/bounds to buffered stdin, or stop consuming/retaining additional lines once the prompt contract has been satisfied. A warning for non-interactive commands receiving unbounded piped input could also help.

A third intentional OOM reproduction was not performed because two kernel kills produced the same 5.1+ GiB signature and the documented --yes flag is a safe workaround.