Repository navigation
Show where a Version's workers run per region - #3995
Draft
rossnelson wants to merge 1 commit into
Draft
rossnelson wants to merge 1 commit into
rossnelson wants to merge 1 commit into
Conversation
Second slice of multi-region Serverless Workers, on top of the model in the previous commit. Still dark unless a consumer passes the Namespace's regions: fewer than two and the Version detail renders exactly what it did before. For a Namespace held in more than one region, the detail now lists each region, which one is active, and what serves it — the provider of its own scaling groups, the default group where it has none of its own, or a warning where nothing serves it at all. That last case is the point of the display: it is the one where a failover finds no workers. A region covered by a catch-all is named as such rather than shown as if it were configured for that region. The difference is what tells someone whether the failover was planned for or merely survivable. The provider decoders each read `scalingGroups[0]`, so a config with more than one group has only ever shown the first — already true for groups split by task queue type, and about to be more visible per region. Each now has a ForGroup form taking the group it should read, and the existing config-level function delegates to it with the first group, so nothing changes for callers that have not said which group they mean. Roles and coverage are marked with data attributes and asserted on those rather than on the rendered words, so rewording a label does not fail the tests.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
4 of 5 tasks
rossnelson
marked this pull request as draft
October 8, 2026 16:19
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second slice of multi-region Serverless Workers. Still dark unless a consumer passes the Namespace's regions — fewer than two and the Version detail renders exactly what it does today.
Description & motivation 💭
For a Namespace held in more than one region, the Version detail now lists each region, which one is active, and what serves it:
That last row is the point of the display. It is the case where a failover to that region finds no workers, and nothing in the UI says so today.
The catch-all case is deliberately distinguished rather than shown as if the region were configured. The difference is what tells someone whether a failover there was planned for or merely survivable.
A pre-existing bug this surfaces
Every provider decoder reads
Object.values(computeConfig.scalingGroups)[0]— only the first group. A config with more than one has always shown just one set of details, which is already reachable today via groups split by task queue type, and becomes far more visible once there is a group per region.Rather than rewrite them, each decoder now has a
...ForGroupform taking the group it should read, and the existing config-level function delegates to it with the first group. Callers that have not said which group they mean get exactly what they got before. 266 existing tests confirm it.Design Considerations 🎨
data-region-role,data-region-match) and the tests assert those rather than the rendered words, so rewording a label does not fail them.aws-us-east-1shows asus-east-1— since the provider is constant across a Namespace's regions today.Testing 🧪
How was this tested 👻
8 new component tests via the isolated Vite SSR harness: the gate in three forms (no regions, one region, and a group naming a region while the Namespace has one), role following the active flag rather than list order, prefix stripping, per-region providers, the uncovered warning, and the catch-all wording.
296 tests pass across deployments, services, utilities and the deployment page.
count-strict-errors.tsreports 0.What comes next
Checklists
Merge Checklist