Skip to content

chore(stack): bump edge-runtime to v1.78.0-r0 - #7502

Merged
supabase-cli-releaser[bot] merged 2 commits into
developfrom
slim-bump/edge-runtime
Nov 5, 2026
Merged

supabase-cli-releaser[bot] merged 2 commits into
developfrom
slim-bump/edge-runtime

Conversation

@supabase-cli-releaser

Copy link
Copy Markdown
Contributor

This bumps edge-runtime from v1.77.9-r0 to v1.78.0-r0.

https://github.com/supabase/slim-services/releases/tag/edge-runtime-v1.78.0-r0

Planned after supabase/slim-services published v1.78.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives.

@github-actions

github-actions Bot commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

CLI benchmark (Lightweight Commands): no changes found

Commit fea24b1 against develop at 95e86b3 · 10 runs each · report only, never blocks merging

Command Workload Before After Change
supabase --version version 287 ms 280 ms no real change
supabase --help help 405 ms 280 ms no real change (-31%, within normal variation)
supabase init init 338 ms 361 ms no real change (+7%, within normal variation)
supabase migration new bench migration-new 291 ms 299 ms no real change
supabase gen types --lang typescript --project-id replayfixtureprojref gen-types 353 ms 353 ms no real change
supabase projects list projects-list 289 ms 288 ms no real change
supabase functions list --project-ref replayfixtureprojref functions-list 293 ms 295 ms no real change

API calls: unchanged for all 7 commands.

Binary size: 134.6 MB, unchanged.

Details: timing ranges, API calls per command, slowest phases

Timing ranges

Command Workload Before range After range Change Verdict
supabase --version version 260-299 ms 262-320 ms -7 ms (-2%) within noise
supabase --help help 243-639 ms 263-413 ms -125 ms (-31%) within noise
supabase init init 233-546 ms 255-620 ms +23 ms (+7%) within noise
supabase migration new bench migration-new 233-413 ms 261-445 ms +7 ms (+3%) within noise
supabase gen types --lang typescript --project-id replayfixtureprojref gen-types 317-455 ms 284-442 ms 0 ms (0%) within noise
supabase projects list projects-list 260-330 ms 235-303 ms -2 ms (-1%) within noise
supabase functions list --project-ref replayfixtureprojref functions-list 260-356 ms 247-339 ms +1 ms (+0%) within noise

API calls per command

Command Workload Before After Endpoint changes
supabase --version version 0 0
supabase --help help 0 0
supabase init init 0 0
supabase migration new bench migration-new 0 0
supabase gen types --lang typescript --project-id replayfixtureprojref gen-types 2 2
supabase projects list projects-list 1 1
supabase functions list --project-ref replayfixtureprojref functions-list 2 2

Slowest phases

No command moved beyond noise, so there are no phase deltas.

Workflow run

Comment /bench to run the lightweight benchmark (this comment) again on the latest commit, or /bench full to also run the integration-heavy benchmark, which posts in its own comment.

@supabase-cli-releaser
supabase-cli-releaser Bot added this pull request to the merge queue Nov 5, 2026
Merged via the queue into develop with commit 4adb0ec Nov 5, 2026
54 checks passed
@supabase-cli-releaser
supabase-cli-releaser Bot deleted the slim-bump/edge-runtime branch November 5, 2026 08:03
kallebysantos pushed a commit to kallebysantos/supabase-cli that referenced this pull request Nov 5, 2026
…pabase#7504)

## TL;DR

Fixes an e2e port race and adds named per-phase deadlines to a test
whose stall cause is still unknown. The `sso list` flake originally in
this PR is already fixed on `develop` by supabase#7502.

- **`status` e2e › reports a running local stack…** failed with Kong's
host port `address already in use`. The e2e helper picked ports by
binding port 0 and releasing it, so they came from the kernel's
ephemeral range, where an outbound connection on the runner could take
one before Docker published it. Ports now come from 1024–9999, below
both the stack's own allocation ranges (10000 and up, see
`packages/stack/src/Ports.ts`) and the OS ephemeral ranges, so neither a
concurrent stack-mode e2e nor an outbound connection can claim a probed
port. Each port is probed on `0.0.0.0`, as Docker binds it, and on
`127.0.0.1`, because macOS lets a wildcard bind succeed over a
loopback-only listener. Ports stay partitioned per e2e worker.
- **`DockerDatabaseStorage` › keeps the prior marker decodable when a
real kill lands…** hit the 20s test timeout and the failure didn't say
which step hung. Each remaining phase (helper image, `prepare`,
PG_VERSION seed, killed writer exit and pipe close, `markInitialized`
retry, both cleanups) now fails with a `PhaseStallError` naming the
phase, well before the test timeout. This is diagnostic-only; the next
failure will name the phase to fix.

## ref

spotted in:
- status e2e:
https://github.com/supabase/cli/actions/runs/41813449030/job/126518169570
- DockerDatabaseStorage:
https://github.com/supabase/cli/actions/runs/41820563616/job/126542347726

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Julien Goux <hi@jgoux.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants