supabase / cli / 28105651597
65%

DEFAULT BRANCH: develop
Ran
Jobs 1
Files 228
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 64.914% (+0.03%) from 64.886%
28105651597

push

github

web-flow 
fix(cli): wait for all image pulls before starting containers (#5681)

## What changed

`supabase start` could start containers before their Docker images had
finished downloading.

The command ran two uncoordinated image-acquisition paths:

1. A best-effort concurrent pre-pull (`pullImagesUsingCompose`) using
docker-compose's `Pull` with `PullOptions{IgnoreFailures: true}`. It
only targets the primary registry and, by design, **silently swallows
per-image pull failures** (the `IgnoreFailures` flag is the hook that
lets the registry fallback recover).
2. An authoritative lazy per-container pull inside `utils.DockerStart` →
`DockerResolveImageIfNotCached` (multi-registry fallback: ECR → GHCR →
Docker Hub).

So any image the concurrent pre-pull failed to cache — a transient
registry/network/rate-limit hiccup, common on a fresh machine pulling
10+ images at once — was pulled **later**, during the `Starting
database… / Starting containers…` phase. That is the "start doesn't wait
for pulls" behaviour from the issue. The pre-pull was added in #4394,
matching the reporter's "last few versions" regression window.

## The fix

Add `ensureImagesCached`, a completeness pass that runs immediately
after the best-effort pre-pull and before any container starts. It
resolves every project image through the **same** multi-registry
fallback resolver `DockerStart` already uses
(`DockerResolveImageIfNotCached`), fanned out concurrently via the
existing `utils.WaitAll` primitive.

After it returns, every required image is guaranteed present in the
local cache, so the per-container `DockerStart` calls become pure cache
hits and never pull mid-start. On the happy path it is just N cheap
image inspects; an image that genuinely cannot be pulled from any
registry now fails the start cleanly **before** any container is
created, instead of limping into a half-pulled start. The compose
pre-pull (and its `IgnoreFailures`) is kept as the fast concurrent
progress UI — it is simply n... (continued)

10890 of 16776 relevant lines covered (64.91%)

10.34 hits per line

Coverage Regressions

Lines Coverage ∆ File
231
66.2
 0.29% internal/start/start.go
39
79.39
 0.15% internal/utils/docker.go
Jobs
ID Job ID Ran Files Coverage
1 28105651597.1 228
64.91
 GitHub Action Run
Source Files on build 28105651597