[jgoux]

A loaded engine can start the container yet keep the start CLI call waiting past its 30s limit, which failed the launch and made the Docker: idle and wake e2e flaky. After a start timeout the launch now inspects the container; if it is running it continues to the readiness checks, otherwise it fails with the original timeout error.

[github-actions]

🤖 AI Review

Both independent reviews reported no findings. Reading the checked-out code confirmed that timeout recovery requires a running container, preserves the original error otherwise, and continues through existing port-publication checks. No concrete defects or fundamental next-branch conflicts found. Tests were not run because dependencies are unavailable.

Findings

No issues found.

Stats

Claude findings: 0 · Codex findings: 0 · Confirmed: 0 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

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

[github-actions]

CLI benchmark (Lightweight Commands): no changes found

Commit 0a3db86 against develop at 5c800b0 · 10 runs each · report only, never blocks merging

Command	Workload	Before	After	Change
supabase --version	version	409 ms	373 ms	no real change (-9%, within normal variation)
supabase --help	help	363 ms	395 ms	no real change (+9%, within normal variation)
supabase init	init	327 ms	335 ms	no real change
supabase migration new bench	migration-new	283 ms	282 ms	no real change
supabase config convert	config-convert	315 ms	328 ms	no real change
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	348 ms	329 ms	no real change (-6%, within normal variation)
supabase projects list	projects-list	261 ms	255 ms	no real change
supabase functions list --project-ref replayfixtureprojref	functions-list	283 ms	296 ms	no real change

API calls: unchanged for all 8 commands.

Binary size: 134.8 MB, unchanged.

Details: timing ranges, API calls per command, slowest phases

Timing ranges

Command	Workload	Before range	After range	Change	Verdict
supabase --version	version	335-499 ms	307-450 ms	-36 ms (-9%)	within noise
supabase --help	help	291-465 ms	294-419 ms	+32 ms (+9%)	within noise
supabase init	init	230-406 ms	284-408 ms	+8 ms (+3%)	within noise
supabase migration new bench	migration-new	248-321 ms	234-314 ms	-1 ms (0%)	within noise
supabase config convert	config-convert	242-394 ms	274-394 ms	+13 ms (+4%)	within noise
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	313-434 ms	287-453 ms	-20 ms (-6%)	within noise
supabase projects list	projects-list	210-345 ms	227-315 ms	-7 ms (-2%)	within noise
supabase functions list --project-ref replayfixtureprojref	functions-list	252-326 ms	233-330 ms	+13 ms (+5%)	within noise

API calls per command

Command	Workload	Before	After	Endpoint changes
supabase --version	version	0	0
supabase --help	help	0	0
supabase init	init	0	0
supabase migration new bench	migration-new	0	0
supabase config convert	config-convert	0	0
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	2	2
supabase projects list	projects-list	1	1
supabase functions list --project-ref replayfixtureprojref	functions-list	2	2

Slowest phases

No command moved beyond noise, so there are no phase deltas.

Workflow run

Comment /bench to run the lightweight benchmark (this comment) again on the latest commit, or /bench full to also run the integration-heavy benchmark, which posts in its own comment.

[jgoux]

Closing: the CI log does not show the server container running while docker start was pending (the earlier pooler output came from its one-off prepare and provision containers), so this change would not have prevented the failure. A follow-up will record the container state when start times out to pin down where it stalls.