functions deploy exits 0 without deploying under concurrent load (138 of 237 functions missing)

[nordgardco]

Running supabase functions deploy under concurrent load returns exit code 0 while the functions are not deployed.

What we measured

On a Supabase branch project, of 237 edge functions 138 were absent afterwards, while the CLI reported success for all 237 and exited 0. No warning and no rate-limit message appeared for those. The absence was confirmed along a second path: GET /v1/projects/<ref>/functions/<slug> returned HTTP 404 "Function not found" for each of them.

Some invocations did fail visibly with:

unexpected list functions status 429: {"message":"ThrottlerException: Too Many Requests"}

but far from all 138.

Why it matters

An automated bootstrap cannot trust the exit code. We now query the API after every round to learn what is actually deployed, and retry only the difference. Anyone who trusts the exit code ships half an environment and reports it as complete.

Question

Can the exit code follow the real result here, or is there a flag that makes the CLI fail on a partial deploy?

Environment

• CLI version: 2.109.1
• Target: Supabase branch project, 237 edge functions
• Invocation: one supabase functions deploy <name> --project-ref <ref> per function, 8 in parallel

[avallete]

Thanks for the report the 138 silent misses (exit 0, no warning) and the visible unexpected list functions status 429 look like two different paths, and we need a bit more from your run to tell them apart.

Could you reply with:

1. Plan of the parent project (Free / Pro / Team / Enterprise)? 237 functions is over the Free cap of 100, and 99 remaining afterwards is close to that number.
2. Fresh branch or redeploy? Were these 237 being created on an empty branch, or updating functions that already existed there / were inherited from the parent?
3. Exact command. Was this the default Docker bundler, or did you pass --use-api? Was Docker running?
4. Per-process outcomes. Of the 237 invocations, roughly how many printed unexpected list functions status 429 (non-zero) vs Deployed Functions on project … (exit 0)? Did any print No change found in Function:?
5. How you confirmed the 404s. Was GET /v1/projects/<ref>/functions/<slug> against the branch ref (same --project-ref as deploy), and was it right after each process or only after the whole wave?
6. Config. Do the functions set verify_jwt in config.toml?

If you still have logs from that run, a redacted sample of one “success but later 404” process (stdout + stderr + exit code) and one 429 process would help a lot.

Also, if you can re-run once on CLI 2.114.0 (npx supabase@2.114.0 …), that would help us rule out anything already fixed. We do not expect it to fix the silent misses if you keep 8 parallel functions deploy <name> processes that path still treats HTTP 201 as success and does not GET the slug afterwards.

Two controls on 2.114.0 would be enough:

# A — same pattern as the report
<deploy each function with 8-way parallelism>

# B — one process, official concurrency
npx supabase@2.114.0 functions deploy --project-ref <branch-ref> --use-api --jobs 8

Then GET /v1/projects/<branch-ref>/functions/<slug> (same ref) and tell us, for A and B: how many 404, how many list 429, how many exit 0.