Skip to content

[Fix] Surface worker provisioning progress and failures on Settings > Sandboxes - #175

Merged
mrubens merged 1 commit into
developfrom
feature/settings-sandboxes-provisioning-state
Jul 11, 2026
Merged

[Fix] Surface worker provisioning progress and failures on Settings > Sandboxes#175
mrubens merged 1 commit into
developfrom
feature/settings-sandboxes-provisioning-state

Conversation

@mrubens

@mrubens mrubens commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Problem

Settings → Sandboxes already receives the detached worker base-image provisioning state and polls while a run is building, but presents none of it:

  • While a run is in flight the save button shows a generic "Saving..." spinner (the setup wizard shows "Provisioning..." for the same state), so a multi-minute Daytona snapshot registration looks like a hung save.
  • A failed run is never displayed. Real incident: saving a Daytona API key that lacked snapshot permissions returned "saved" in the UI while the registration died server-side with Access denied — the only evidence was in the web service logs.

Change

ComputeProviderSection now matches the wizard's presentation:

  • Button reads "Provisioning..." while provisioning.status === 'building', with a note that the run can take a few minutes.
  • A failed run renders its persisted error in a destructive alert (falling back to generic copy when no error was recorded), and the button reads "Retry provisioning" when credentials are already satisfied (this label branch existed but rendered "Save").

No data-flow changes — the page already polled and passed provisioning; this is presentation only.

Testing

  • New ComputeProviderSection.client.test.tsx covering the building, failed-with-error, failed-without-error, and idle states.
  • pnpm lint:fast, pnpm check-types:fast, pnpm knip all pass.

… Sandboxes

The settings page already received the detached provisioning state and
polled while a run was building, but rendered it as a generic
"Saving..." spinner and never displayed a failed run at all — an
operator saving a Daytona key with insufficient permissions saw the
save succeed and nothing else, while the registration died with
"Access denied" server-side.

Match the setup wizard's presentation: label the button
"Provisioning..." during the run with a note that it can take a few
minutes, show the persisted error inline after a failure, and offer
"Retry provisioning" when credentials are already satisfied.
@roomote-roomote

roomote-roomote Bot commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

No code issues found. See task

Reviewed this presentation-only change: the button now reads Provisioning.../Retry provisioning (matching the setup wizard) and a failed run surfaces its persisted error inline. Data flow is unchanged — ComputeProviders already polls compute.status while a run is building and passes the per-provider provisioning state (including error) into the section. The building/failed branches are mutually exclusive and render inside the expanded section. The new ComputeProviderSection.client.test.tsx covers the building, failed-with-error, failed-without-error, and idle states and passes locally.

@mrubens
mrubens merged commit f82d167 into develop Jul 11, 2026
1 check passed
@mrubens
mrubens deleted the feature/settings-sandboxes-provisioning-state branch July 11, 2026 06:35
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