Repository navigation
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 4 files. (7 skipped: 7… | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation Linked Issues check Issue [ #1922] requires a warning on stderr after a dispatched release, one JSON document on stdout, explicit continuing-cost and no-teardown text, and regression tests.fleet.tscallsdeps.warnon…Out of Scope Changes check The changed source implements only the warning behavior requested by issue [ #1922]. The CLI does not add Cloud/provider deletion. The tests and RelayFlow proof verify the warning, stdout contract, fai…Title check The title clearly and concisely describes the main change: warning that fleet release does not tear down Cloud sandboxes. Description check The description includes the required Summary, Test Plan, RelayFlow Proof, and Screenshots sections. It describes the behavior, tests, proof case, validation limits, and maintenance requirements.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 4 files. (7 skipped: 7 unsupported.)
- Fix all pre-merge checks with AI
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit reads the release note at dawn,
“The sandbox may keep running,” it says.
One warning hops to stderr,
The JSON receipt stays in its place.
No teardown follows the dispatched call,
And carrots are counted before the next hop.
Comment @coderabbitai help to get the list of available commands.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| if (released.status === 'dispatched') { | ||
| deps.warn( | ||
| 'Release was dispatched. If this worker is sandbox-backed, its Cloud/provider sandbox may keep running and incurring cost; `fleet release` does not tear it down.' | ||
| ); | ||
| } |
There was a problem hiding this comment.
🟡 Completed releases omit sandbox cost warning
When agents.release returns completed, the CLI omits the sandbox warning despite a successful release. Sandbox-backed workers can keep incurring cost without notice; a pending release dispatched later has the same gap.
Learn more
The workspace lifecycle client passes through release receipts from the server without converting their status. A release can return completed immediately, as shown by the lifecycle test; pending work can also dispatch after this command returns. Neither state triggers the warning, although the release command never calls sandbox deletion.
Example: A sandbox-backed worker receives {status: 'completed'} from the release API. The command prints its receipt and exits without mentioning that the Cloud sandbox can remain running.
Recommended fix: Warn on successful release acknowledgements without requiring the transient dispatched state. For pending receipts, use wording that does not claim dispatch has already occurred; retain the one-document stdout contract.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
A successful
fleet releasedispatch can leave a Cloud/provider sandbox running and incurring cost. Warn on stderr after adispatchedacknowledgement while retaining the existing single JSON document on stdout, including--delete-agentand--delete-agent --wait. This change does not request sandbox teardown.Fixes #1922.
Adds seven regression tests, one RelayFlow bugfix proof case, a patch changelog entry, and tracked Trail records.
Test Plan
npm run typecheckpasses with Git's Unix tools on PATH for the existing build scripts.git diff --checkpass. The same runner observesbugon exact basec1ffabbc4andfixedon exact headd4119014e; neither observation is selected from the proof arm.Validation limits: the complete fleet file has 114 passing tests and one Windows path failure in
--checkout keeps cross-repo --cwd inference on the actual checkout while using the explicit project workspace(/workspace-projectversusC:\workspace-project). Unchanged base reproduces the same failure with 107 passing tests. The broader Windows suite (npm test --ignore-scripts -- --reporter=json) did not pass: its report records 3,040 passed, 342 failed, and 38 pending tests, and a worker ran out of heap memory. Maintainer validation on Linux remains outstanding. Fork PRs also require a maintainer to reproduce the branch and proof case in the upstream repository before the credential-bearing Cloud proof can run, per the case README.RelayFlow Proof
bugfix1922-fleet-release-sandbox-warningScreenshots
Not applicable; CLI warning only.
Need help on this PR? Tag
@codesmith-botwith what you need.Note
Low Risk
Adds a stderr-only user warning after a successful dispatched release; release semantics, JSON stdout, and sandbox teardown behavior are unchanged.
Overview
fleet releasenow emits a single stderr warning when the lifecycle API returnsstatus: 'dispatched', telling operators that a sandbox-backed worker’s Cloud/provider sandbox may keep running and incur cost and thatfleet releasedoes not tear it down. The existing one JSON document on stdout is unchanged, including with--delete-agent/--wait.Coverage adds seven CLI regressions, a RelayFlow bugfix proof (
1922-fleet-release-sandbox-warning), an Unreleased patch changelog entry, and issue-1922 trajectory metadata.Reviewed by Cursor Bugbot for commit d411901. Bugbot is set up for automated code reviews on this repo. Configure here.