Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Explicit local function bundling falls back to API bundling when Docker is unavailable

Aperta
  • Qualcosa non va?
#7,214 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
docker, typescript
Ambito
cli, devops

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

🐛 Bug supabase/cli

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.

Lingua principale
TypeScript
Stelle
2.4k
Fork
537
Merge medio
20h 14m
PR unite (30g)
412

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di supabase/cli

Tutte le issue di supabase/cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.