Skip to content

feat(deployments): show worker deployment connection status by default - #3852

Draft
rossnelson wants to merge 3 commits into
mainfrom
reexpose-connection-status
Draft

feat(deployments): show worker deployment connection status by default#3852
rossnelson wants to merge 3 commits into
mainfrom
reexpose-connection-status

Conversation

@rossnelson

@rossnelson rossnelson commented Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

DO NOT MERGE until cloud release 3.161 rolls out past ring-0

The frontend deploys to every ring at the same time. An unflagged
re-expose is correct in ring-0 and incorrect in every other ring. Merge
this only after 3.161 covers all rings that serve the UI.

Summary

  • show the connection status by default: the Connection column on the
    deployment detail page, and the status inside the compute pill on the
    deployments list
  • keep showConnectionStatus, so a consumer can still hide the column
    without a release of this package
  • restore the Validate Connection guidance in the Pending tooltip
  • extend the unit and integration tests to cover the re-exposed path,
    which includes the detail row colspan

Why

PR #3718 hid the connection status behind showConnectionStatus, which
defaults to false. The UI was correct. Two backend defects made the
column show a permanent Pending status:

Both fixes are merged. Cloud release 3.161 carries them.

Where the flip belongs

The prop defaults to false here, and no route in this repo or in
cloud-ui passes it. Three options:

  1. Flip the default here. One change, one repo. Every consumer gets
    the column. This PR takes this option.
  2. Pass true from cloud-ui. This needs a change to four route files
    in a second repo and a UI pack bump, and it leaves a dead prop here.
    It does not solve the ring problem either, because cloud-ui also
    deploys to every ring at the same time.
  3. Gate on a server capability. This is the only mechanism that lets
    ring-0 show the column while later rings hide it, because the server
    reports its own support per cell. No such capability exists.
    serverScaledDeployments is true on 3.158 and on 3.161 alike, so it
    selects the broken set, not the fixed set. A new capability needs a
    change to temporalio/api, to the server, and to cloud, which takes
    longer than the rollout it would guard.

Option 1 with the prop kept gives the same rollback lever at lower cost:
cloud-ui can pass showConnectionStatus={false} if a ring turns out to
be behind.

Pending tooltip copy

Commit e6efe42 removed "or use Validate Connection to check now"
because the on-demand validation was a dry run. WCI#99 makes that
statement correct again. handleValidateSpec now writes the validation
status and signals the version workflow when the request carries no
scaling group changes, which is what the manual action sends. The row
already refreshes after a validation, so the badge changes in place.

The 6h claim stays. The default of
workercontroller.periodic_validation_interval_s is 21600 seconds.

Client contract

validateCurrentWorkerDeploymentVersionComputeConfig keeps its void
return. ValidateWorkerDeploymentVersionComputeConfigResponse is an
empty message, so the earlier { valid, message } shape never matched
the server.

The verdict does not need that shape. handleValidateSpec returns
InvalidArgument for a failed check, and it carries the same message it
writes to provider_validation.error_message. A success returns an empty
200. The modal and the badge cannot disagree.

Test plan

  • pnpm lint: 0 errors
  • pnpm check: 0 errors across 851 files
  • pnpm test -- --run: 3029 passed, 2 skipped
  • pnpm test:integration: 315 passed, 1 skipped
  • preview URL against a cell on 3.161

@rossnelson
feat(deployments): show worker deployment connection status by default
ce0070b 
Change the default of showConnectionStatus to true on the deployments
list, the deployment detail page, and both table rows. This shows the
Connection column and the connection badge to every consumer of the
package, which includes cloud-ui.

Keep the prop. A consumer that must hide the column can still pass
showConnectionStatus={false} without a release of this package.

Two backend defects made the column show a permanent Pending status.
Both are corrected:

- temporalio/temporal-auto-scaled-workers#99 lets an empty ValidateSpec
  request validate the current configuration and persist the result.
- temporalio/temporal#11273 sends syncSummary(), so an updated
  ComputeStatus reaches the deployment workflow that
  DescribeWorkerDeployment reads.

Cover the re-exposed path in the tests. The unit tests show the column
by default, keep the opt-out, and add a Pending version. The integration
test shows the persisted status, then changes the badge from Pending to
Connected to Failed across two validations.
@rossnelson
feat(deployments): tell the user how to check a pending connection now
92f4af3 
Restore the Validate Connection guidance in the Pending tooltip.

Commit e6efe42 removed this guidance because the on-demand validation
was a dry run that did not write to compute_status. That is no longer
correct. In temporalio/temporal-auto-scaled-workers#99, handleValidateSpec
writes the validation status and signals the version workflow when the
request carries no scaling group changes, which is what the manual
Validate Connection action sends.

Keep the 6h interval. The default of the dynamic configuration setting
workercontroller.periodic_validation_interval_s is 21600 seconds.
@vercel

vercel Bot commented Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
holocene Ready Ready Preview Aug 20, 2026 7:40pm

Request Review

@rossnelson

rossnelson commented Aug 20, 2026

Copy link
Copy Markdown
Collaborator Author

Preview is blocked by an unrelated breaking change on main

The first preview build failed, and the cause is not in this PR.

Run: https://github.com/temporalio/cloud-ui/actions/runs/32403417274 (the pack
build succeeded)
Generated PR: temporalio/cloud-ui#3130, branch test-ui-92f4af39

On that PR, Vercel, check-types, and unit-tests all fail with errors of this
shape:

Object literal may only specify known properties,
and '"trailingIcon"' does not exist in type 'ButtonWithHrefProps'.

These come from #3822, refactor(icons)!: replace holocene's icon registry with Io icon components, which merged earlier today as commit 403e5b9. cloud-ui
still uses the removed props: 27 uses of trailingIcon and 50 of leadingIcon.
This branch starts from 4 commits after that refactor, so it inherits the
breakage.

Evidence that this PR is not the cause: the last test PR before the refactor,
temporalio/cloud-ui#3128 from ui commit 99b026bf, passed Vercel.
Commit 99b026b is not a descendant of 403e5b9. The failing check-pack job
is also normal for a test PR, because it reports the expected .ui-sha change.

To see the feature, a second preview builds the same two commits on the commit
before the icon refactor. It is branch preview/reexpose-connection-status-pre-icons,
and it is a throwaway for the preview only. Its deployment change set is
identical to this PR: 4 changed lines in each of the four gated files and the
same string change.

cloud-ui needs an update for #3822 before a preview of this branch as it stands
can build.

@rossnelson

rossnelson commented Aug 20, 2026

Copy link
Copy Markdown
Collaborator Author

Preview is live, built from a pre-refactor base

Preview URL: https://cloud-ui-git-test-ui-54483a7f.preview.thundergun.io
Generated PR: temporalio/cloud-ui#3131, branch test-ui-54483a7f
Run: https://github.com/temporalio/cloud-ui/actions/runs/32404421290

Vercel reports DEPLOYED and the URL answers 200.

This preview carries the same two commits as this PR, applied to dd80eca05,
which is the commit before the icon refactor. The change set is identical: 4
changed lines in each of the four gated files, plus the same string change. Its
branch and its cloud-ui PR are throwaway. Delete both after use.

What the preview shows is the UI. It does not confirm the feature end to end.
The cell it points at is not known to run 3.161. Against an older cell the badge
shows a permanent Pending, which is the backend gap this PR waits on, not a UI
defect.

Still to check by hand, with a signed-in session:

  • Connection column on the detail page, status inside the compute pill on
    the list page
  • Pending, Connected, and Failed states, each with the correct colour and
    tooltip
  • Validate Connection changes the badge in place after the row reloads
  • the restored Pending tooltip sentence reads correctly at width

@rossnelson
fix(deployments): separate a check that fails from a check that does …
0aa28cf 
…not finish

Report an incomplete validation as unknown, not as an invalid connection.

A 504 from the validate-compute-config endpoint made the modal say
"Connection is invalid". The gateway timed out, so the check never
returned a verdict. The connection can be correct.

The backend reports a completed check that finds a problem as
InvalidArgument, which maps to HTTP 400 and carries the message it also
writes to provider_validation.error_message. Treat that status alone as a
verdict. Report every other failure, which includes 5xx, a lost
connection, and statuses such as 401 and 404, as an unknown result.

Add a third modal state for this. It shows a neutral icon, says the
status is unknown, and tells the user the check can still complete.

Refresh the row for all outcomes. A check that does not return to the
browser can still finish and persist a status.
@rossnelson

rossnelson commented Aug 20, 2026

Copy link
Copy Markdown
Collaborator Author

Rebuilt preview, with the gateway timeout fix

Preview URL: https://cloud-ui-git-test-ui-2bff5f80.preview.thundergun.io
Generated PR: temporalio/cloud-ui#3133, branch test-ui-2bff5f80
Run: https://github.com/temporalio/cloud-ui/actions/runs/32430114522

Vercel reports DEPLOYED and the URL answers 200. This build supersedes
cloud-ui#3131, which predates commit 0aa28cf3.

To check the corrected path, run Validate Connection against a version whose
provider is slow enough to time out at the gateway. The modal must read "Could
not complete the check" with a neutral icon, must not read "Connection is
invalid", and the badge must hold the status the server last reported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@rossnelson