fix(start): suggest recovery for exec format and backup migration failures#5936
Conversation
…lures Surface actionable CmdSuggestion when unhealthy containers log exec format error, storage migrations_name_key, or Studio ERR_INVALID_PACKAGE_CONFIG, and pin image pulls to linux/<host-arch> to reduce wrong-arch Mailpit starts.
|
👋 Thanks for the contribution! This pull request isn't linked to a tracked issue, so it's being closed automatically. Please open an issue first, wait for a maintainer to add the |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4031555019
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| "A container failed with \"exec format error\" (wrong CPU architecture image).\n"+ | ||
| "Try removing the mismatched images and restarting for linux/%s:\n"+ | ||
| " %s\n"+ | ||
| " docker image prune -f\n"+ |
There was a problem hiding this comment.
Remove tagged wrong-arch images explicitly
For the cached wrong-architecture image case that produces exec format error, this recovery command does not actually remove the bad image: Docker's image prune docs (https://docs.docker.com/reference/cli/docker/image/prune/) define the default as removing only dangling images unless -a is used, while the image Supabase just started is still tagged and will be reused by DockerResolveImageIfNotCached on the next supabase start. Users who follow the suggestion can therefore hit the same health-check failure again; the hint needs to remove the relevant cached image tag(s) or force a repull.
Useful? React with 👍 / 👎.
| parts = append(parts, fmt.Sprintf( | ||
| "Studio image looks corrupted or incomplete. Remove it and re-pull:\n"+ | ||
| " %s\n"+ | ||
| " docker image rm -f $(docker images -q supabase/studio) 2>/dev/null\n"+ |
There was a problem hiding this comment.
Remove the registry-qualified Studio image
When Studio was pulled through the normal registry resolution path, the cached repository is usually public.ecr.aws/supabase/studio first, then ghcr.io/supabase/studio, not supabase/studio; after this command, supabase start can still inspect and reuse the corrupted registry-qualified image, so the ERR_INVALID_PACKAGE_CONFIG recovery suggestion fails for the default install path. Please target the resolved registry candidates or the running container's image ID instead of only the Docker Hub name.
Useful? React with 👍 / 👎.
| RegistryAuth: GetRegistryAuthForImage(imageTag), | ||
| // Prefer the host architecture so services like mailpit do not start | ||
| // with a wrong-arch binary (exec format error). See supabase/supabase#48224. | ||
| Platform: "linux/" + runtime.GOARCH, |
There was a problem hiding this comment.
Propagate the platform pin to compose pulls
This platform pin only applies to DockerImagePull, but a normal supabase start first runs pullImagesUsingCompose and only then ensureImagesCached; the compose path goes through RetryClient.ImagePull with options.Platform left empty. When that best-effort pre-pull succeeds for a missing service image, the later resolver sees the tag cached and never reaches this pinned pull, so the wrong-arch image this change is meant to prevent can still be introduced during startup. Set the same platform on the compose pull/project path or validate the cached image platform before accepting it.
Useful? React with 👍 / 👎.
| RegistryAuth: GetRegistryAuthForImage(imageTag), | ||
| // Prefer the host architecture so services like mailpit do not start | ||
| // with a wrong-arch binary (exec format error). See supabase/supabase#48224. | ||
| Platform: "linux/" + runtime.GOARCH, |
There was a problem hiding this comment.
Use the daemon architecture for remote Docker pulls
When the CLI talks to a Docker daemon with a different architecture from the CLI binary, such as a remote DOCKER_HOST or an amd64 dev container using an arm64 host socket, runtime.GOARCH is the client architecture rather than the daemon's. This forces the daemon to pull linux/<client-arch> images and can recreate the same exec-format/no-matching-manifest startup failures on the remote host; query the daemon platform or avoid overriding Docker's default when the daemon architecture is not known.
Useful? React with 👍 / 👎.
Summary
exec format error, storagemigrations_name_key, and StudioERR_INVALID_PACKAGE_CONFIGin unhealthy container logs and setCmdSuggestionwith recovery steps (supabase stop --no-backup, re-pull / prune).DockerImagePulltolinux/<host-arch>so wrong-arch Mailpit images are less likely to start.Test plan
go test ./internal/db/start/ -run TestSuggestFromUnhealthyLogs