stack: a database helper stays behind as a `Created` container when readiness times out mid-create
Maintainer thường phản hồi trong vòng 1 ngày
Một pull request liên quan đã được merge.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 18/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- docker, typescript
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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).
- Ngôn ngữ chính
- TypeScript
- Star
- 2.4k
- Fork
- 533
- Merge trung bình
- 22 giờ 20 phút
- Pull request đã merge (30 ngày)
- 370
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của supabase/cli
-
🐛 Bug supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructiveCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở✨ Feature supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
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 requestCó thể đã có người làm @7ttp đã nhận 12 ngày trước. Đang mở🐛 Bug supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
supabase/cli#6975 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
📘 Docs supabase/cli
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
supabase/cli#6974 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Migration error caret is missing or misplaced when the statement contains multibyte charactersĐang mở🐛 Bug supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
xdjs/MusicNerdWeb#1532 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
sebastian-software/ardo#352 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
@react95/core good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 3 ngày
-
@shikijs/stream: `ShikiStreamTokenizer.clone()` shares its `tokensStable` array with the originalCó thể đã có người làm @xyrolle đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 6 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày