fix(cli): stop db start hanging on a stalled docker (CLI-2066)

[7ttp]

TL;DR

db start no longer hangs forever when the docker CLI binary stalls: the already-running check now asks the Docker Engine API directly.

What's hurting the users?

Since v2.110.0 the check spawns docker container inspect and waits on it. If that binary hangs, db start shows nothing, starts nothing, and never exits (#6110). v2.109.1 was immune because it called the Engine API instead of spawning a subprocess...

Now fixed by

The probe resolves the daemon endpoint the same way the docker CLI does (DOCKER_HOST, then the context store, then the platform default) and sends GET /containers/<id>/json over the local socket or named pipe.

anything that is not a clean Engine 200 or 404 falls back to the old spawn path, so error messages,
daemon-down handling, and Podman support stay exactly as they are today.
db reset --local, db diff --use-pgadmin, and the declarative flows share the same probe and get the same fix...

Ref

• Closes Windows CLI 2.111.0: supabase db start hangs silently before contacting Docker #6110
• Regressed by feat(cli): port db push, db reset, and db start to native TypeScript #5715

[github-actions]

Supabase CLI preview

npx --yes https://pkg.pr.new/supabase/cli/supabase@0618b9ca599cf12f5f10f9f300d4e0229b84eee9

Preview package for commit 0618b9c.

[7ttp]

/ai-review

[github-actions]

🤖 AI Review

Both reviews completed. After verification, the 10 reported findings merge into 9 distinct findings, all confirmed. No critical or major defects were identified; the findings comprise four minor reliability/coverage/observability concerns and five documentation or test-organization nits.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:126	reliability	claude	The Engine probe has only a socket-inactivity timeout, so a peer that continually trickles data can keep the probe running far beyond two seconds.
🟡 MINOR	apps/cli/src/commands/db/start/start.integration.test.ts:1832	test-coverage	claude	The Windows named-pipe transport is not exercised by a real transport test or CI job.
🟡 MINOR	apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:221	observability	claude	The Engine request bypasses DebugLogger.http, so its debug output lacks the established HTTP-request format; optional layer-time logger lookup also makes missing wiring silent.
🟡 MINOR	apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:134	test-coverage	claude	Several new probe branches, including oversized and interrupted responses and debug tracing, lack tests.
⚪ NIT	apps/cli/src/command-internal/db-bootstrap/local-db-running.ts:81	documentation	claude	The comments cite ControlHttpReader as precedent, but that symbol is not defined or referenced anywhere else in the repository.
⚪ NIT	apps/cli/src/commands/db/start/start.integration.test.ts:1743	test-organization	claude+codex	Tests for the shared local-db-running component are placed in the db-start handler suite instead of being colocated with their implementation.
⚪ NIT	apps/cli/src/commands/start/services/vector.service.unit.test.ts:17	test-organization	claude	Direct tests for platformDefaultDockerHost remained in the vector service suite after the helper moved to hostname.ts.
⚪ NIT	apps/cli/src/commands/db/reset/SIDE_EFFECTS.md:127	documentation	claude	db reset documents the new Engine request and Docker context files but omits the Docker environment variables now consumed in process.
⚪ NIT	apps/cli/src/commands/db/start/SIDE_EFFECTS.md:121	documentation	codex	The API side-effects table inaccurately says the Engine probe uses only the response status.

Stats

Claude findings: 8 · Codex findings: 2 · Confirmed: 9 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5 + gpt-5.6-sol · Trigger: manual · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.

[depthfirst-app]

🟡 Severity: MEDIUM

DOCKER_HOST and Docker context endpoints can carry credentials in URI userinfo (for example, ssh://user:password@host). This new --debug fallback logs redactHttpUrl(endpoint), but that helper only strips selected query parameters and preserves userinfo, exposing daemon credentials in stderr and copied CI logs.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: The root cause is that redactHttpUrl in apps/cli/src/auth/http-debug.layer.ts only redacts URLs containing presigned query-string parameters, and returns the URL unchanged when parsed.search === "" — which is always the case for Docker daemon endpoints like ssh://user:password@host or tcp://user:password@host. Fix redactHttpUrl by unconditionally stripping URI userinfo before any other checks: immediately after successfully parsing the URL (after line 50), add parsed.username = ""; parsed.password = ""; and then build the return string from parsed.href instead of the raw input when there is no presigned query. This ensures userinfo credentials are never emitted to stderr or CI logs regardless of scheme or query string. Note that the same redactHttpUrl is also called at line 219 for the full container-inspect URL, so fixing the helper protects both call sites. As a secondary hardening measure, consider replacing the debug message at line 228 with a fixed string like "non-socket endpoint" rather than logging any form of the endpoint value, since its host/path adds no debugging value in the fallback-to-CLI branch where the full URL is already known to be unusable for direct socket access.