supabase functions download fails with 'invalid eszip v2' — appears to be eszip version skew in the extraction container

[kmhari]

Hitting this on CLI 2.101.0. Deploying a function with supabase functions deploy ping works fine — it pulls the bundler image, bundles, uploads, and the function runs correctly when I invoke it over HTTP. But trying to download the same function back fails immediately:

$ supabase functions download ping --project-ref <ref>
Downloading function: ping
invalid eszip v2
error running container: exit 1

If your function is deployed using CLI < 1.120.0, trying running supabase functions download --legacy-bundle ping instead.

--legacy-bundle doesn't help either — it just blows up inside the wasm parser:

panicked at 'unreachable'
   at https://deno.land/x/eszip@v0.30.0/eszip_wasm_bg.wasm:1:1862894
   at __wbg_adapter_18 (eszip_wasm.generated.js:146:6)
   at real (eszip_wasm.generated.js:130:14)

I poked around to figure out what was actually going wrong. I grabbed the multipart response from GET /v1/projects/<ref>/functions/<slug>/body directly with curl and pulled out just the file part, then compared it byte-for-byte to the bundle the server has on disk. Identical — magic bytes ESZIP2.3 either way:

$ head -c 16 bundle.eszip | xxd
00000000: 4553 5a49 5032 2e33 0000 0004 0000 0100  ESZIP2.3........

So nothing's getting mangled in transit. The CLI's own bundler image (supabase/edge-runtime:v1.73.13, which the CLI pulls itself when I run deploy) just produced these bytes minutes earlier. But when download runs and tries to read them — whether through the docker container path or the bundled deno.land/x/eszip@v0.30.0 wasm path — both reject them as invalid v2.

Looks like the writer side moved to ESZIP2.3 but the reader side (whichever runtime image download spins up, plus the in-process wasm fallback) is still on something older that only goes up to 2.2. The CLI's writer and reader are out of sync within the same release.

Tried this against both self-hosted (running edge-runtime v1.74.0, latest) and the symptom is the same. From the related issues below, it sounds like Cloud users hit similar download issues — though their failure modes are different so probably not the same root cause.

Sanity: my CLI version is 2.101.0 (homebrew), Docker is running (29.2.1), function deploys cleanly with all current tooling. Just can't get it back.

Workarounds I considered if anyone else hits this:

• --legacy-bundle — no, also fails (wasm panic above)
• --use-api deploy path (raw source) — download presumably works there since the server holds plain .ts files; but you'd have had to deploy that way originally
• Don't lose your source 🙃

Possibly related but different symptoms:

• Cannot use supabase functions download #1912 — old issue, silent extraction to /home/deno (different shape, already closed)
• _shared folder not extracted with docker #5000, bug: folder extraction not working #5086 — _shared/ not extracted with Docker (partial extraction, parse succeeds — mine fails the parse)