Explicit local function bundling falls back to API bundling when Docker is unavailable
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 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
- 平均マージ
- 19時間 48分
- マージ済み PR（30日）
- 405
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 が 2 日前に担当しました。 オープン🐛 Bug supabase/cli
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
supabase/cli#7087 · コメント 2 件 ·
メンテナーはふだん 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 日以内に返信
-
📘 Docs supabase/cli
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
supabase/cli#6974 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
🐛 Bug supabase/cli
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
🐛 Bug supabase/cli
難易度 4/5 3〜5日 初心者へのやさしさ 54/100
supabase/cli#7200 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
area: app type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
ExpidetGames/code-reviewer#585 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 83/100
module-federation/core#5205 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
LanternOps/breeze#9392 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
engine-rs P3 review-deferral wasm
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
maniator/verticopolis#1154 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信