feat: keep the sandbox provider step visible when runtime env satisfies it#403
Conversation
|
No new code issues found. See task
Reviewed 0782db0 |
…es it Mirrors the communication/source-control treatment from #388 for the compute step: runtime env vars alone no longer count as a choice, so a deployment that preconfigures a sandbox provider (e.g. Roomote Sandbox) still renders the picker — preselected, one click, nothing to fill in — instead of silently skipping it. The step completes on a genuine choice: the wizard pick or a persisted Settings default. Also scopes the compute-config skip to the chosen provider: a deployment-wide setupSatisfied (another provider fully configured by env vars) previously skipped configuration for an unconfigured provider the user picked, e.g. bring-your-own E2B on a deployment with a seeded managed provider. A chosen provider missing from the offered list has no config step to render (the stale-choice guard covers exclusions), which preserves behavior for statuses without provider entries.
aa200b6 to
179843e
Compare
configSatisfied only proves a provider can run, not that dispatch targets it: saveComputeProviderChoice deliberately defers the runtime default to the config confirmation for credential-backed providers, so choosing an already-configured provider skipped config and advanced the wizard while dispatch kept the previous default. Both halves per review: the choice mutation now commits the default when the chosen provider is already fully configured (the wizard skips its config step, so the choice is the confirmation — same reasoning as the existing credentialless path), and the compute-config skip additionally requires the chosen provider to be the effective persisted/runtime default, so a canonical /setup re-entry with pre-fix persisted state renders config once and commits through its confirmation.
|
Addressed in
New coverage: command tests for commit-on-configured-choice and no-commit-on-unconfigured-choice; a flow test pinning configured-but-not-default → |
The compute-config recovery path (re-confirming an already-configured provider to commit it as the dispatch default) could dead-end: with saved credentials and an already-provisioned artifact but a locked local-tag DOCKER_WORKER_IMAGE, Continue stayed disabled on the hosted worker-image requirement while every earlier step was skipped, leaving no route out. Saving only derives or provisions from the worker image when a required managed artifact (base image ref, template id, snapshot name, image) is still unsatisfied, so the requirement now applies exactly then. Fresh hosted setups keep the guard; the E2B disable-test fixture gains the managed template field it was missing (real catalogs always carry one), and a new test pins the recovery path continuing on a local-tag image.
|
Addressed in Test updates: the fresh-E2B disable test's fixture gains the |
The previous commit scoped only the Continue guard, so the recovered already-provisioned state enabled Continue while still warning that the locked DOCKER_WORKER_IMAGE must be set before continuing, with the advanced section forced open. missingHostedWorkerImage now carries the pending-managed-infrastructure predicate, driving the warning, the auto-opened advanced section, and the Continue guard together. The misleading-advanced-toggle test fixture now clears defaultSatisfied on the base image ref when its worker image is not hosted-ready — those cannot diverge in production since the default derives from that image — and the recovery test asserts the warning no longer renders.
|
Addressed in |
Same catalog comment mechanism as Local Docker's 'Run on this host'.
1 participant
Stacked on #402 (base branch is
feat/roomote-cloud-compute-provider; retarget todevelopafter it merges).What
Mirrors #388's communication/source-control treatment for the compute step, which was the remaining step that silently vanished when env vars preconfigured a provider:
compute-providercompletes only on a genuine choice (the wizard pick or a persisted Settings default) — runtime satisfaction alone no longer skips it. A deployment that preconfigures a sandbox provider still shows the picker with that provider preselected: one click, nothing to fill in, but the user sees what they're getting and that alternatives exist.compute-configskip is scoped to the chosen provider. Previously the deployment-widesetupSatisfiedshort-circuit meant that on a deployment with a preconfigured provider, choosing an unconfigured bring-your-own provider (e.g. E2B) skipped its credential step entirely — the same scoping bug [Improve] Let users choose a setup provider even when its env vars are already configured #388 fixed for source control.No changes to the picker UI or persistence — the existing
saveComputeProviderChoiceflow already persists the choice and short-paths credentialless providers past the config step.Tests
Two new
useSetupFlowcases: the seeded-deployment picker-still-renders scenario, and the chosen-unconfigured-provider-still-configures scenario. Full web client project passes (201 files / 1395 tests); lint and check-types clean.