…810)

**What changed?**
Added `ComputeStatus` to the Worker Deployment API with a
`ProviderValidationStatus` that tracks the result of the most recent
connectivity check between Temporal and a customer's compute resource.
An empty error message means validation passed; a non-empty message
describes what failed.

**Why?**
Enables surfacing the connectivity health between Temporal and a
customer's compute resource (e.g. Lambda) through the Worker Deployment
API, so the UI can show ongoing validations status of compute configs
without additional queries.

**Breaking changes**
None. All additions are new optional fields; existing clients are
unaffected.

**Server PR**
temporalio/temporal#10778

…(#810)

**What changed?**
Added `ComputeStatus` to the Worker Deployment API with a
`ProviderValidationStatus` that tracks the result of the most recent
connectivity check between Temporal and a customer's compute resource.
An empty error message means validation passed; a non-empty message
describes what failed.

**Why?**
Enables surfacing the connectivity health between Temporal and a
customer's compute resource (e.g. Lambda) through the Worker Deployment
API, so the UI can show ongoing validations status of compute configs
without additional queries.

**Breaking changes**
None. All additions are new optional fields; existing clients are
unaffected.

**Server PR**
temporalio/temporal#10778

## What changed?
`DescribeWorkerDeployment` now returns compute status per version,
checking whether Temporal can successfully interact with the version's
compute resource. `ListWorkerDeployments` also returns compute status on
the current, ramping, and latest version summaries, fetched in parallel.

When connectivity changes (e.g. Lambda becomes unreachable or is
restored), WCI signals the version workflow, which propagates the update
to the deployment workflow memo. The list view reads from the memo —
versions that have been validated since deployment will show their
status immediately; others will appear once the first validation runs.

## Why?
Allows customers to see whether Temporal can successfully interact with
their compute resource directly from the Worker Deployments list and
detail views, without navigating into each individual version.

## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)

…ts (DT-4174) (#3618)

* Add connection status types, util, and ConnectionBadge (DT-4174)

Phase 1-2 of DT-4174 (connection status on Deployments/Versions).

- Add ProviderValidation/ComputeStatus types + computeStatus on VersionSummaryNew
- Add deriveConnectionStatus + formatConnectionCheckTime pure utils with tests
- Add ConnectionBadge component (dot + word + tooltip) and i18n keys

State is derived client-side from compute_status.provider_validation
(error_message + last_check_time): pending / connected / failed. The
failure message from the API is rendered directly (no client-side code map).

These phases are API-independent and degrade to Pending until the backend
(temporalio/api#810, temporalio/temporal#10778) lands. List/details wiring
and the configurable Latest Version column are follow-ups.

* Wire connection status into deployments list and versions table (DT-4174)

Phase 3-4 of DT-4174.

List page: replace the Latest Version column with a composite Current
Version cell (build ID + compute + connection badge); show No Current
Version when there is no current version. Latest Version as an optional
column is a follow-up.

Details page: add a Connection column to the versions table, shown for
Current/Ramping/Draining versions and an em dash otherwise. All new UI is
behind the serverScaledDeployments capability; the validate-connection
flow is unchanged.

* Only show connection status when a compute config is present (DT-4174)

Self-managed (non-serverless) deployments have no compute provider, so a
connection indicator is meaningless for them. Gate the ConnectionBadge on
the compute provider being present: the list Current Version cell shows it
alongside the compute badge, and the versions table shows an em dash when
there is no compute config. Found via local testing against a self-managed
worker deployment.

* Match designs: connection inside compute pill, Lifecycle header (DT-4174)

- List Current Version cell renders the connection dot + word inside the
  compute pill (Lambda • Connected) instead of as a separate badge, per design
- ComputeBadge accepts children so the connection can be composed inside it
- Rename the versions-table lifecycle column header to Lifecycle

* Refine connection dot: smaller/centered in pill, hidden in details column (DT-4174)

- Shrink the in-pill status dot (size-2 -> size-1.5) and shrink-0 so it stays
  small and vertically centered next to the label, matching the design
- Add showDot prop to ConnectionBadge (default off); the list pill opts in, the
  details Connection column renders the word only

* Flatten connection into the compute pill layout (DT-4174)

Move the connection rendering into ComputeBadge via a computeStatus prop so
the icon, label, status dot, and status word are direct flex children of one
pill (Lambda • Connected), with the tooltip on the pill. ConnectionBadge is
now the word-only badge used by the details Connection column.

* Add Storybook story showing all connection/compute scenarios (DT-4174)

Showcases the composite pill across providers x Connected/Failed/Pending,
compute-only (self-managed), and the details word-only ConnectionBadge.

* Use design-system status colors + story render tests (DT-4174)

- Connection colors use design tokens (text-success/text-danger/text-subtle)
  instead of raw green/red; the in-pill dot uses bg-current so it matches
- Add Storybook play() render assertions for each connection scenario
  (Lambda/Cloud Run x Connected/Failed/Pending, compute-only), runnable via
  pnpm stories:test

* Drop misleading Validate Connection hint from Pending tooltip (DT-4174)

The on-demand Validate Connection API is a dry-run and does not persist to
compute_status, so it does not update the connection badge. Remove the
implication that it does.

* Extract shared connection presentation helpers (DT-4174)

Both ComputeBadge (list pill) and ConnectionBadge (details column) duplicated
the state->color map, state->label, and tooltip-text logic. Move them to
connection-status.ts (connectionStateColor, connectionStateLabel,
connectionTooltip) so there is a single source of truth; the components are
now thin presentational shells.

* Consolidate duplicate connection tooltip i18n key (DT-4174)

connection-tooltip-connected and connection-tooltip-failed-checked were the
same string ('Checked {{ time }}'). Replace both with a single state-neutral
connection-tooltip-checked key used by connectionTooltip for the connected
and failed states.

* Route connection freshness text through i18n (DT-4174)

formatConnectionCheckTime previously returned hardcoded English (date-fns
output + a literal 'less than an hour ago'). Replace with translate keys
(connection-checked-recently/-hour/-hours) and a manual hour calc, dropping
the date-fns dependency from this helper. Output is unchanged for the
existing states.

* Add Latest Version optional column to Deployments list (DT-4174) (#3625)

* Add Latest Version optional column to Deployments list (DT-4174)

The second half of DT-4174. Latest Version is an opt-in, hidden-by-default
column on the Worker Deployments list, toggled via the table's
configurable-columns drawer (the same control Workflows/Schedules/Activities
use).

- Extend the configurable-table-columns store with a DEPLOYMENTS table type:
  DEFAULT_DEPLOYMENTS_COLUMNS (Deployment, Current Version, Created At) with
  Latest Version as an available/hidden column, a namespace-scoped
  persistStore, and availableDeploymentColumns.
- Source the deployments list columns from the store, translate labels for
  the header, and add the footer gear + reused drawer.
- The Latest Version cell renders build ID, lifecycle status, and compute
  provider, with no connection indicator (connection stays on Current
  Version). Shows 'Same as Current' when the latest version equals the
  current one, and an em dash when there is no latest version.
- Gate the drawer's custom search attributes section off for deployments so
  it does not show an irrelevant empty section (workflows/schedules/
  activities are unaffected).

* Tighten deployment list version cells (DT-4174)

Match the design for the Current and Latest Version cells on the deployments
list:

- Remove the min-w-32 on the build-ID container so the compute badge sits
  next to the build ID instead of leaving a large gap for short IDs.
- Drop the copy button from the build-ID cells (not shown in the design); the
  deployment name keeps its copy button.

* Remove compute-badge Storybook story (DT-4174)

Drop the compute-badge story to check whether it is the source of the
Chromatic UI Tests failure.

* Revert "Remove compute-badge Storybook story (DT-4174)"

This reverts commit e07018c.

* Address review nits (DT-4174)

- formatConnectionCheckTime: guard against NaN diff (invalid dates) and use
  Math.floor so elapsed hours are not overstated. Add an invalid-date test.
- Remove the now-unused 'build-status' i18n key (replaced by 'lifecycle').
- Configurable-columns MOVE reducer: fall back to the table-aware
  defaultColumns instead of hardcoded DEFAULT_WORKFLOWS_COLUMNS.

…10778)

## What changed?
`DescribeWorkerDeployment` now returns compute status per version,
checking whether Temporal can successfully interact with the version's
compute resource. `ListWorkerDeployments` also returns compute status on
the current, ramping, and latest version summaries, fetched in parallel.

When connectivity changes (e.g. Lambda becomes unreachable or is
restored), WCI signals the version workflow, which propagates the update
to the deployment workflow memo. The list view reads from the memo —
versions that have been validated since deployment will show their
status immediately; others will appear once the first validation runs.

## Why?
Allows customers to see whether Temporal can successfully interact with
their compute resource directly from the Worker Deployments list and
detail views, without navigating into each individual version.

## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)

## What changed?
`DescribeWorkerDeployment` now returns compute status per version,
checking whether Temporal can successfully interact with the version's
compute resource. `ListWorkerDeployments` also returns compute status on
the current, ramping, and latest version summaries, fetched in parallel.

When connectivity changes (e.g. Lambda becomes unreachable or is
restored), WCI signals the version workflow, which propagates the update
to the deployment workflow memo. The list view reads from the memo —
versions that have been validated since deployment will show their
status immediately; others will appear once the first validation runs.

## Why?
Allows customers to see whether Temporal can successfully interact with
their compute resource directly from the Worker Deployments list and
detail views, without navigating into each individual version.

## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)