stack: a database helper stays behind as a `Created` container when readiness times out mid-create
メンテナーはふだん 1 日以内に返信
関連するプルリクエストがすでにマージされています。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 18/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 停滞
- 技術スタック
- docker, typescript
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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).
- 主要言語
- TypeScript
- スター
- 2.4k
- フォーク
- 533
- 平均マージ
- 1日 5時間
- マージ済み PR（30日）
- 338
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
supabase/cli のほかの issue
-
🐛 Bug supabase/cli
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructive再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン✨ Feature supabase/cli
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
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 request対応中かも @7ttp が 10 日前に担当しました。 オープン🐛 Bug supabase/cli
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
📘 Docs supabase/cli
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
supabase/cli#6974 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
🐛 Bug supabase/cli
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
documentation good first issue hacktoberfest help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
libredb/libredb-studio#1756 ·
メンテナーはふだん 1 日以内に返信
-
state:triage-needed
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
lingdojo/kana-dojo#32365 · コメント 1 件 · リアクション 5 件 ·
メンテナーはふだん 1 日以内に返信
-
friction
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
kentcdodds/kody#3706 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
copperheadhq/copperhead#378 ·
メンテナーはふだん 1 日以内に返信