stack: a database helper stays behind as a `Created` container when readiness times out mid-create
I maintainer di solito rispondono entro 1 giorno
@just-some-random-pal ci sta già lavorando.
Dal 8/10/2026.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 18/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Ferma
- Stack tecnologico
- docker, typescript
Direzione di ricerca
Start in DockerDatabaseStorage.startAttachedHelper, where the helper is launched with docker run --rm -i and removed with rm -f on timeout, then check the fake engines in DockerDatabaseStorage.integration.test.ts and the permissive fake in Container.integration.test.ts. Linked PR #7068 is already open, so confirm its status before starting. Done means the helper can be removed by name whether or not it became ready, and the fake-engine tests cover a create that outlasts the timeout.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Affected area
Local development
Supabase CLI version
v2.121.0-beta.11; the code path is the develop stack runtime after #7014.
Operating system
macOS 26.4, Docker Engine 25.0.3 (Docker Desktop)
Installation method
npm
Command
docker ps -a --filter label=com.supabase.stack-managed=true --filter status=created
Actual output
A supabase-db-helper-<id> container in Created state that nothing ever starts. It carries the stack labels and still references the database volume, so a following stack destroy runs destroyNamespace against a volume that this container holds.
How it happens: DockerDatabaseStorage.startAttachedHelper starts the helper with docker run --rm -i --name <name> … and waits up to 30 seconds for the ready line. On timeout it kills the run client and removes the helper with rm -f <name>. But run creates the container on the daemon side, and that create keeps going after the client dies. If the create itself outlasts the timeout, rm -f runs before the container exists and finds nothing. The daemon then finishes the create, nothing starts the container, --rm never fires, and the Created container is left behind. @jgoux reproduced it by killing a run client mid-create (https://github.com/supabase/cli/pull/7014#discussion_r4206642325); @avallete confirmed the mechanism and suggested handling it as a separate change.
Expected output
No container is left behind. Every helper the stack created can be removed by name, whether or not it became ready.
Additional context
Proposed fix, as discussed in #7014: start the helper with docker create --rm -i --name <name> … followed by docker start --attach --interactive <name>. The name then exists before any readiness timeout can fire, so rm -f always finds it. create --rm -i sets the same AutoRemove and StdinOnce as run --rm -i (checked on Docker 29 in that thread), so stdin EOF from a dead attached client still ends the helper. Scope: the helper start, the three fake engines in DockerDatabaseStorage.integration.test.ts, the permissive fake in Container.integration.test.ts, and a re-check on Podman.
I have this implemented on a branch and will open the PR once this issue is labeled open-for-contribution (the Contribution Gate closed #7062 for lacking a linked issue).
- Lingua principale
- TypeScript
- Stelle
- 2.4k
- Fork
- 531
- Merge medio
- 1g 4h
- PR unite (30g)
- 351
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di supabase/cli
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructiveForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta✨ Feature supabase/cli
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
stack: the HTTP gateway closes idle keep-alive connections after 5 s, so a client whose event loop is blocked gets ECONNRESET (`fetch failed`) on its next requestForse già presa @7ttp l’ha presa 6 giorni fa. Aperta🐛 Bug supabase/cli
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
supabase/cli#6975 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
📘 Docs supabase/cli
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
supabase/cli#6974 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Migration error caret is missing or misplaced when the statement contains multibyte charactersAperta🐛 Bug supabase/cli
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
🐛 Bug supabase/cli
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
supabase/cli#7055 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di supabase/cli
Issue simili
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
lingdojo/kana-dojo#32018 · 1 commento · 5 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
paperclipai/paperclip#15751 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
BuilderIO/agent-native#7275 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno