refactor(blaze): separate sandbox API handlers - #2585
Draft
WeissonHan wants to merge 3 commits into
Draft
Conversation
Reset changed only lifecycle metadata before returning the same runtime to an instance pool. It did not reset runtime or storage, so callers could receive a false success and later reuse state they expected to discard. Return 501 for running reset requests while preserving 400, 404, and 422 for malformed, missing, and invalid-state requests. Remove the inactive pool implementation because reset was its only source of reusable instances. Keep the four pool routes as 501 compatibility endpoints. Reject unsupported pool settings, but accept and ignore only the exact defaults shipped in older RPM configuration and policy files. This narrow exception prevents an administrator-modified %config(noreplace) file from blocking the upgraded binary before the operator can merge its .rpmnew replacement. Retain decoding for legacy Reset and Warm states, including persisted start_path = warm records, so startup cleanup can release their resources. Remove the three metrics that no longer describe a supported operation. This is a breaking correction for clients using the incomplete pool API, unsupported pool configuration, or removed metrics. Complete reusable-instance support remains out of scope and must arrive with sandbox creation that uses it. Fixes: 1f0cfac ("feat(anvil): scaffold local orchestrator crate skeleton") Signed-off-by: Weisson Han <wenshu.hx@linux.alibaba.com>
Route the seven shared sandbox operations through canonical sandbox handlers. Keep /v1/instances behind explicit compatibility adapters that reuse the same request fields, response fields, status codes, and resource side effects. Keep instance-only reset and checkpoint routing explicit. Retain the legacy instance destroy action as an adapter to canonical deletion. Do not register sandbox reset, checkpoint, or action-style destroy routes. Signed-off-by: Weisson <Weisson@linux.alibaba.com>
Document /v1/sandboxes as the canonical namespace and /v1/instances as an explicit compatibility layer for the seven shared operations. Preserve the existing JSON fields, status codes, and resource effects. Explain the instance-only reset, checkpoint, and legacy destroy routes, and state that their sandbox action counterparts remain unregistered. Signed-off-by: Weisson <Weisson@linux.alibaba.com>
Collaborator
Author
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Why
The
/v1/sandboxesand/v1/instancesroutes currently share match arms and handler names. Their runtime behavior is intentional, but the code does not make it clear that sandboxes are the canonical resource and instances are a compatibility namespace. That ambiguity makes follow-up API changes harder to review without accidentally expanding compatibility-only actions.This Draft separates those roles while preserving the existing HTTP contract.
What changed
Related issue
Closes #2577.
Temporary semantic prerequisite: #2290.
Integration validation also covers #2293 and #2296. Those two pull requests are not part of this branch's public ancestry and are not presented as API-0 code dependencies.
User / Agent impact
New integrations should use
/v1/sandboxes. Existing/v1/instancesclients continue to use the same request fields, response fields, status codes, and resource effects. In particular, the JSON fieldsinstanceandinstance_idare unchanged, and no compatibility removal date is introduced.No new endpoint is added. Sandbox reset, checkpoint, and action-style destroy remain unregistered and return 404.
Risk and compatibility
The checked item reflects a documentation and code-ownership clarification of the public API namespaces. Runtime routing behavior, wire formats, status codes, and side effects remain unchanged.
Draft status and temporary base
This is a provisional stacked Draft and must not be marked ready or merged in its current form.
mainatba20d94d19a73e5b781cab0c687d4034ad0d0dae.adbe1c1220b426e3340877c0599f31d9c2f4237c.aca85ff4672a435d7bae6da8e6f0bed2c62078ef.3bcf1afee00787cd119258f97af61f6ca21a57f3.main..headrange therefore includes fix(blaze)!: reject incomplete reset and pool use #2290. The API-0-owned range starts afteradbe1c1220.9daea49ed7a8adc35a62b8b7db2d44079d61b230and fix(blaze): drain accepted HTTP connections #2296 at9b593cf6181decf2234bf929864f181622ba469fwere included only in a private integration candidate.Before this Draft can become ready, #2290, #2293, and #2296 must reach their planned disposition. The two API-0 commits will then be rebuilt on the exact current
main, andmain..headmust contain only those two commits and their seven intended paths. Per-commit, final-head, merge-candidate, hosted, and exact-head Codex review gates will all be rerun.Any change to the recorded
mainor prerequisite heads makes the corresponding validation below historical evidence.Validation
Public exact commits were independently fetched from GitHub and tested on Linux x86_64 with Rust/Cargo 1.88,
--locked --offline, fresh source trees, fresh Cargo homes, and fresh target directories for every stage.For both
aca85ff4672and3bcf1afee0:cargo fmt --all -- --checkA private integration candidate combined the recorded
main, #2290, #2293, #2296, and these two API-0 patches. The API-0 patches replayed without conflicts. Its final tree wasdc8f65cd2add8796c62f86eb3a0652eced8e4b96and passed the same Linux matrix, including 339 default and 354 all-feature tests. Exact focused tests passed for API-0 (7/7), #2290 (17/17), #2293 (15/15), and #2296 (21/21).The exact GitHub merge candidate
d055f0f9f9de427f7d0513a13156908a62e89fff(tree6b0e5d29e78fe5ea415dd1818c22bd79504b43db) was also fetched independently and passed the full Linux matrix: 303 default tests, 318 all-feature tests, API-0 focused tests 7/7, and #2290 focused tests 17/17. Its 29 changed paths are exactly the union of the recorded #2290 paths and the seven API-0 paths.All four hosted workflows completed successfully. Codex reviewed exact head
3bcf1afee0and reported no major issues; no inline review thread was opened. GitHub's public checks did not expose an independent CLA status, so this Draft does not claim one.Documentation and rollback
Updated only the existing English and Chinese Blaze README and user guide. No design document or changelog was added or restored.
There is no data or configuration migration. During the Draft phase, rollback is the removal or reversion of the two API-0 commits. Before final submission, the branch will be rebuilt from current
mainrather than carrying the temporary prerequisite ancestry forward.