-
Notifications
You must be signed in to change notification settings - Fork 50
fix(cloud-agent-next): preserve classified assistant terminal failures #4659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
eshurakov
wants to merge
1
commit into
main
Choose a base branch
from
eshurakov/cloud-agent-improvements
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
87 changes: 87 additions & 0 deletions
87
docs/superpowers/specs/2026-07-22-cloud-agent-e2e-health-design.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| # Cloud Agent E2E Health Reliability Design | ||
|
|
||
| ## Goal | ||
|
|
||
| Make the local fake-LLM smoke matrix a reliable health check for the real Cloud Agent path: Worker, Durable Object, sandbox container, wrapper, Kilo, and persisted run reporting. The harness must distinguish genuine product regressions from expected warm-session preparation chatter and from local container-engine cleanup races. | ||
|
|
||
| ## Scope | ||
|
|
||
| This change is limited to the local E2E harness under `services/cloud-agent-next/test/e2e` and its focused unit tests and documentation. It does not change Worker, wrapper, or UI behavior. It does not add retries. | ||
|
|
||
| ## Warm-Reuse Health Contract | ||
|
|
||
| The `hot` and `cold-hot` scenarios must continue to prove all of the following: | ||
|
|
||
| - the follow-up reaches its expected terminal state; | ||
| - the first Kilo event arrives within the existing observation window; | ||
| - the original primary sandbox remains present; | ||
| - no new sandbox container appears; and | ||
| - no live preparation step that represents cold workspace work starts. | ||
|
|
||
| Preparation snapshots replayed when a stream connects are historical state, not evidence of new work. Live `attempt_started`, `attempt_completed`, progress, and completion frames are also not sufficient by themselves to prove reprovisioning. The harness will therefore classify only version 2 `preparing` frames with `action: "step_started"`. | ||
|
|
||
| The following steps are expected during a warm verification and do not indicate reprovisioning: | ||
|
|
||
| - `sandbox_provision` | ||
| - `sandbox_boot` | ||
| - `kilo_server` | ||
|
|
||
| Any other live `step_started` preparation step is cold-path work and fails warm reuse. This deliberately fails closed for newly introduced step names: a new step must be explicitly classified before the health check accepts it. Legacy unversioned `preparing` frames also fail warm reuse because the harness cannot prove that they are harmless snapshots or warm verification. | ||
|
|
||
| Failure output will report the unexpected preparation step names instead of only printing `noPrepare=false`. | ||
|
|
||
| ## Matrix Isolation Contract | ||
|
|
||
| After every matrix row, the harness will: | ||
|
|
||
| 1. identify sandbox families created after the matrix baseline; | ||
| 2. kill their currently running primary/proxy containers using the existing exact-family matching; | ||
| 3. wait for each selected family to disappear; and | ||
| 4. poll all non-baseline sandbox containers until none exist continuously for five seconds. | ||
|
|
||
| The continuous absence window covers the observed local container-engine `destroy -> create -> destroy` churn after an external kill. If a new non-baseline sandbox appears during the window, the stability timer resets. The total quiescence wait is bounded. | ||
|
|
||
| If cleanup does not quiesce, the matrix records an explicit cleanup failure and stops before running another scenario in contaminated state. It does not silently warn and continue, sleep for a fixed interval, or retry a failed product scenario. | ||
|
|
||
| Baseline containers are never killed or treated as cleanup failures. | ||
|
|
||
| ## Components | ||
|
|
||
| ### Preparation classification | ||
|
|
||
| A small pure helper in `lifecycle.ts` will return the unexpected cold preparation steps observed in a stream event list. Both `hot` and `cold-hot` will use it. | ||
|
|
||
| ### Sandbox quiescence | ||
|
|
||
| `sandbox-control.ts` will own a bounded stable-absence polling helper because it already owns Docker discovery and family operations. Its Docker executor and timing inputs will be injectable for deterministic unit tests while production callers use defaults. | ||
|
|
||
| `smoke.ts` will use the helper after its existing family cleanup and convert failure into an explicit matrix result before stopping. | ||
|
|
||
| ### Documentation | ||
|
|
||
| The E2E README will describe the warm-reuse and between-row isolation assertions so operators know what a failure means. | ||
|
|
||
| ## Tests | ||
|
|
||
| Focused unit tests will cover: | ||
|
|
||
| - snapshots and warm verification steps do not count as cold preparation; | ||
| - cold-path and legacy preparation events do count; | ||
| - the stable-absence window succeeds only after uninterrupted absence; | ||
| - a transient recreation resets the stability window; | ||
| - persistent non-baseline containers time out; and | ||
| - baseline containers are ignored. | ||
|
|
||
| Focused verification will run the new unit tests, service typecheck, formatting checks, and `git diff --check`. | ||
|
|
||
| Runtime verification will run the complete 15-row matrix against the current local stack with `WORKER_URL=http://localhost:10594`. Completion requires 15/15 scenario results and no matrix-cleanup failure. | ||
|
|
||
| ## Deferred Work | ||
|
|
||
| The following remain separate follow-ups: | ||
|
|
||
| - suppressing no-op preparation attempts in production to remove the warm UI flash; | ||
| - retrying matrix scenarios; | ||
| - removing stopped Docker container corpses; | ||
| - adding provisioning elapsed-time landmarks; and | ||
| - cleaning pre-existing proxy containers. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SUGGESTION: Duplicate classification entries
Lines 38-39 (
{ failureStage: 'agent_activity', failureCode: 'payment_required' }/'model_missing') duplicate lines 35-36 added by the same PR. SinceCloudAgentRunFailureClassificationsfeeds aSet-based validator, the duplicates are functionally harmless, but they look like an unintended copy-paste and should be removed for clarity.Reply with
@kilocode-bot fix itto have Kilo Code address this issue.