Skip to content

chore(stack): bump edge-runtime to v1.77.4-r0 - #6955

Merged
jgoux merged 1 commit into
developfrom
slim-bump/edge-runtime
Oct 2, 2026
Merged

jgoux merged 1 commit into
developfrom
slim-bump/edge-runtime

Conversation

@supabase-cli-releaser

Copy link
Copy Markdown
Contributor

This bumps edge-runtime from v1.77.2-r0 to v1.77.4-r0.

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

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

@supabase-cli-releaser
supabase-cli-releaser Bot requested a review from a team as a code owner October 2, 2026 07:25
@jgoux
jgoux added this pull request to the merge queue Oct 2, 2026
Merged via the queue into develop with commit f19b82d Oct 2, 2026
46 checks passed
@jgoux
jgoux deleted the slim-bump/edge-runtime branch October 2, 2026 07:38
therickys93 pushed a commit to therickys93/cli that referenced this pull request Oct 5, 2026
…upabase#6957)

`slim-release-published.yml` force-pushes one branch per service release
line. When that branch's PR sits in the merge queue, GitHub rejects the
push (GH006) and the job used to fail, dropping the planned pin until
the next upstream release. On 2026-10-01 this lost edge-runtime
v1.77.4-r0: the v1.77.3-r0 and v1.77.4-r0 dispatches both hit
`slim-bump/edge-runtime` while supabase#6930 was queued (restored by supabase#6955).

When a push is rejected because the branch is queued for merging, the
Apply step now:

- waits for the queue to merge or drop that PR, polling `isInMergeQueue`
for up to 30 minutes and within the app token's lifetime;
- stops processing the current plan, so no remaining item is built from
the pre-merge base;
- re-sends the same dispatch so a fresh run re-plans from the updated
default branch, at most three times in a row (tracked by a validated
`client_payload.replay` counter).

The concurrency group now keeps every pending run (`queue: max`) instead
of replacing the pending one, so a replay can never cancel a newer
dispatch and its release-visibility wait. A failed queue lookup or
dispatch, a queue that holds the branch past the deadline, an exhausted
replay budget, and any other push rejection still fail the run with the
manual recovery command. ADR 0026 documents the behavior.
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.

1 participant