Explicit local function bundling falls back to API bundling when Docker is unavailable
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- docker, typescript
调研方向
Start by tracing the Edge Functions deploy path that handles --use-api=false, Docker availability checks, and API source uploads; the issue does not name source files or tests. Reproduce with a Docker stub that fails and confirm explicit local packaging stops before an API deployment request. Add regression coverage for the unavailable-Docker and precheck-race cases, while confirming default automatic fallback remains unchanged.
由索引模型根据 Issue 内容生成。
描述
Supabase CLI 2.121.0 attempts API source deployment with --use-api=false when its Docker check fails. The same occurs when an external Docker precheck succeeds and Docker becomes unavailable before the CLI checks it. Combining --use-api=false and --use-docker is rejected by the existing mutex.
This was reproduced with the installed macOS arm64 executable using synthetic credentials and a synthetic project, an OS sandbox denying external networking and real credential access, and a Docker stub. A supported file profile pointing to an owned loopback mock independently captured the API source-upload request. No real provider write occurred.
Expected behavior: explicit local packaging fails before an API deployment request when Docker is unavailable, while default automatic fallback remains unchanged. PR #7213 contains a narrow correction with regression tests, but was automatically closed by the contribution gate. Please triage this bug and, if appropriate, add open-for-contribution so the correction can follow the contribution workflow.
Affected area
Edge Functions / Docker
Supabase CLI version
2.121.0, Homebrew macOS arm64 binary, SHA-256 6e8be5fb2802ccdd247d3b47823c31ed8d7e792255048594ba32ee79a55208dc.
Operating system
macOS (arm64).
Command
The command below uses a generic relative profile path. It was run inside verified OS containment, with synthetic credentials and the file profile pointing exclusively to an owned loopback mock:
supabase functions deploy probe --use-api=false --project-ref abcdefghijklmnopqrst --profile ./local-profile.yaml --debug
Actual output
Machine-specific paths and timestamps have been removed from this excerpt; the observed CLI behavior is unchanged.
Loading profile from flag: ./local-profile.yaml
Using access token from env var...
Supabase CLI 2.121.0
Using profile: contained (contained.invalid)
Using access token from env var...
WARNING: Docker is not running
Uploading asset (probe): supabase/functions/probe/index.ts
HTTP POST: http://127.0.0.1:58516/v1/projects/abcdefghijklmnopqrst/functions/deploy
The mock captured the corresponding source-upload POST. Exit zero reflects the mock response, not hosted delivery. A separate all-network-denied run without profile redirection also logged an attempted Management API deploy POST, which the OS blocked.
Steps to reproduce
Use an isolated task HOME, cleared environment, synthetic access token/project and an OS sandbox denying external network access and real credential/keychain access. Establish those denial checks before entering the deployment path. Use a dependency-free probe handler with verify_jwt=false, and a supported file profile redirecting API requests to an owned loopback mock. Put a Docker stub that exits1 on PATH and invoke the command above inside containment; observe the API source-upload request despite explicit --use-api=false.
For the precheck race, make the stub return0 once for an external docker info, then1 for the CLI's subsequent check. The same fallback occurs. A synthetic project ref alone does not provide containment.
Verification limits
These reproductions establish transport selection. Real Docker packaging and actual runtime bundler-error handling were not verified by this harness. The proposed correction preserves default automatic fallback and existing targeting/JWT behavior; it adds no deployment wrapper.
- 主要语言
- TypeScript
- 星标
- 2.4k
- 派生
- 537
- 平均合并
- 20 小时 14 分钟
- 30 天内合并 PR
- 412
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
supabase/cli 的其他 Issue
-
config push: changing auth.oauth_server.authorization_url_path fails with 400 (enabled and path must be sent together)可能已有人在做 @itz-puneet 于 3 天前认领。 未关闭🐛 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可能重新可做 关联的 PR 已关闭且未合并。 未关闭✨ Feature supabase/cli
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
📘 Docs supabase/cli
难度 1/5 1 小时以内 新手友好度 88/100
维护者通常 1 天内回复
-
🐛 Bug supabase/cli
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
🐛 Bug supabase/cli
难度 4/5 3-5 天 新手友好度 54/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
mobile-next/mobile-mcp#526 ·
维护者通常 1 天内回复
-
e2e-failure ready-to-code
难度 1/5 1 小时以内 新手友好度 73/100
redhat-developer/rhdh-plugin-export-overlays#4470 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
anthropics/anthropic-sdk-typescript#1273 ·
维护者通常 10 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
CopilotKit/OpenBot#815 ·
维护者通常 1 天内回复