On a failed or interrupted provisioning operation, the step that was waiting when it failed still shows Waiting with a clock icon, and its phase gets the blue in-progress border. That contradicts the Failed badge directly above it.
provisioning-presentation.ts:48 takes a step's state from its check result before looking at the operation's state, so a check left at waiting still reads "Waiting" after the operation fails.
ProvisioningProgress.svelte:22 gives any phase containing a waiting step the current style.
Steps after the failure show "Not recorded", because "Not run" is only used for cancelled operations (provisioning-presentation.ts:52).
This happens when a container stays unhealthy: native.ts:718 records the container check as waiting, and once recovery has already restarted and rebuilt the instance, native.ts:410-413 fails the operation with that check still waiting.
Screenshots
From the synthetic UI preview. Progress records and a launch recipe were added to the disposable fixture database using the labels the worker records. "After" images are mockups made in an uncommitted copy.
Before:
After (mockup):
Fix
On failed and interrupted operations, show the waiting or current step as failed ("Stopped here")
Show the steps after it as "Not run"
Don't apply the in-progress style to phases of a finished operation
On a failed or interrupted provisioning operation, the step that was waiting when it failed still shows **Waiting** with a clock icon, and its phase gets the blue in-progress border. That contradicts the **Failed** badge directly above it.
- `provisioning-presentation.ts:48` takes a step's state from its check result before looking at the operation's state, so a check left at `waiting` still reads "Waiting" after the operation fails.
- `ProvisioningProgress.svelte:22` gives any phase containing a waiting step the `current` style.
- Steps after the failure show "Not recorded", because "Not run" is only used for cancelled operations (`provisioning-presentation.ts:52`).
This happens when a container stays unhealthy: `native.ts:718` records the container check as `waiting`, and once recovery has already restarted and rebuilt the instance, `native.ts:410-413` fails the operation with that check still `waiting`.
**Screenshots**
_From the synthetic UI preview. Progress records and a launch recipe were added to the disposable fixture database using the labels the worker records. "After" images are mockups made in an uncommitted copy._
Before:
After (mockup):
**Fix**
- [x] On failed and interrupted operations, show the waiting or current step as failed ("Stopped here")
- [x] Show the steps after it as "Not run"
- [x] Don't apply the in-progress style to phases of a finished operation
Reviewed 29c2e3ba00. All three fix items are done, so I'm closing this.
Checklist
Stopped step shows as failed. On failed and interrupted operations, a waiting step, or the current step without conclusive evidence, now becomes failed (provisioning-presentation.ts:64), and that state reads "Stopped here" (provisioning-presentation.ts:79). Completed evidence is kept. The check's own recorded waiting result isn't changed, so the checks list still shows what the agent actually reported.
Later steps show "Not run". Steps after the current phase now get the cancelled state ("Not run") for failed and interrupted operations as well as cancelled ones (provisioning-presentation.ts:61).
No in-progress style on finished operations. The current class and aria-current="step" now apply only while the operation is active (ProvisioningProgress.svelte:23,39).
Review notes
Good extra: the new tests render the component and check the markup, not just the state mapping. The unhealthy-container case reads "Stopped here" twice (phase and step) and "Not run" three times, with no "Waiting", the failed class, and no current class or aria-current. A separate test confirms stale waiting evidence isn't highlighted on done, warning, cancelled, failed or interrupted operations.
I checked whether a stale waiting check could mark a second step as "Stopped here" after unhealthy recovery. It can't: queueing a recovery restart or rebuild resets the checks to an empty list (native.ts:463).
"Needs attention" was only used by this component, so the relabel doesn't change any other page.
The 3 related test files pass locally (213 tests), and npm run check reports 0 errors.
Reviewed 29c2e3ba004f9d156b23372ce1796eca23291e82. All three fix items are done, so I'm closing this.
**Checklist**
- [x] **Stopped step shows as failed.** On failed and interrupted operations, a waiting step, or the current step without conclusive evidence, now becomes `failed` (`provisioning-presentation.ts:64`), and that state reads "Stopped here" (`provisioning-presentation.ts:79`). Completed evidence is kept. The check's own recorded `waiting` result isn't changed, so the checks list still shows what the agent actually reported.
- [x] **Later steps show "Not run".** Steps after the current phase now get the `cancelled` state ("Not run") for failed and interrupted operations as well as cancelled ones (`provisioning-presentation.ts:61`).
- [x] **No in-progress style on finished operations.** The `current` class and `aria-current="step"` now apply only while the operation is active (`ProvisioningProgress.svelte:23,39`).
**Review notes**
- Good extra: the new tests render the component and check the markup, not just the state mapping. The unhealthy-container case reads "Stopped here" twice (phase and step) and "Not run" three times, with no "Waiting", the `failed` class, and no `current` class or `aria-current`. A separate test confirms stale waiting evidence isn't highlighted on done, warning, cancelled, failed or interrupted operations.
- I checked whether a stale waiting check could mark a second step as "Stopped here" after unhealthy recovery. It can't: queueing a recovery restart or rebuild resets the checks to an empty list (`native.ts:463`).
- "Needs attention" was only used by this component, so the relabel doesn't change any other page.
- The 3 related test files pass locally (213 tests), and `npm run check` reports 0 errors.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On a failed or interrupted provisioning operation, the step that was waiting when it failed still shows Waiting with a clock icon, and its phase gets the blue in-progress border. That contradicts the Failed badge directly above it.
provisioning-presentation.ts:48takes a step's state from its check result before looking at the operation's state, so a check left atwaitingstill reads "Waiting" after the operation fails.ProvisioningProgress.svelte:22gives any phase containing a waiting step thecurrentstyle.provisioning-presentation.ts:52).This happens when a container stays unhealthy:
native.ts:718records the container check aswaiting, and once recovery has already restarted and rebuilt the instance,native.ts:410-413fails the operation with that check stillwaiting.Screenshots
From the synthetic UI preview. Progress records and a launch recipe were added to the disposable fixture database using the labels the worker records. "After" images are mockups made in an uncommitted copy.
Before:
After (mockup):
Fix
Reviewed
29c2e3ba00. All three fix items are done, so I'm closing this.Checklist
failed(provisioning-presentation.ts:64), and that state reads "Stopped here" (provisioning-presentation.ts:79). Completed evidence is kept. The check's own recordedwaitingresult isn't changed, so the checks list still shows what the agent actually reported.cancelledstate ("Not run") for failed and interrupted operations as well as cancelled ones (provisioning-presentation.ts:61).currentclass andaria-current="step"now apply only while the operation is active (ProvisioningProgress.svelte:23,39).Review notes
failedclass, and nocurrentclass oraria-current. A separate test confirms stale waiting evidence isn't highlighted on done, warning, cancelled, failed or interrupted operations.native.ts:463).npm run checkreports 0 errors.