docs(sandbox): say the Azure binding lacks these, not the cloud - #465
Closed
ItamarZand88 wants to merge 1 commit into
Closed
docs(sandbox): say the Azure binding lacks these, not the cloud#465ItamarZand88 wants to merge 1 commit into
ItamarZand88 wants to merge 1 commit into
Conversation
The capability docs stated that Azure's data plane exposes no file transfer and takes no egress policy. Microsoft documents both as ADC data-plane capabilities, so what is absent is this binding's implementation of them. The distinction is not pedantic. Two of these strings are generated into the published schema and zod artifacts, so the claim reaches anyone reading the package, and it tells them a capability is impossible when it is unbuilt. The assertion message was the worst of them: whoever implements the Azure file operations will hit that failing test and be told the data plane cannot do what they just made it do. Assertions and behaviour are unchanged; the capability set still reports files and egressDeny false for Azure, which is correct for what a caller can reach today.
Contributor
Author
|
Reopened as a branch that satisfies the naming convention CI enforces; same commit, same content. |
Greptile SummaryThis documentation-only PR clarifies that Azure sandbox file-transfer and egress-policy limitations belong to the current binding implementation rather than Azure’s underlying data plane.
Confidence Score: 5/5The PR appears safe to merge because it only corrects documentation and diagnostic wording to match the existing implementation. The revised descriptions agree with the current Azure capability flags, unsupported file-operation methods, and egress validation behavior, with no runtime or public data-shape changes.
|
| Filename | Overview |
|---|---|
| crates/alien-core/src/resources/sandbox.rs | Corrects Azure capability descriptions and test diagnostics while leaving capability values, validation, and assertions unchanged. |
| packages/core/src/sandbox.ts | Updates public TypeScript documentation to accurately attribute unsupported file transfer and hostname egress allowlists to binding implementations. |
Reviews (1): Last reviewed commit: "docs(sandbox): say the Azure binding lac..." | Re-trigger Greptile
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.
Summary
The sandbox capability docs said Azure's data plane exposes no file transfer and takes no egress policy. Microsoft documents both as ADC data-plane capabilities, so what is absent is this binding's implementation of them. Wording only — no assertion and no behaviour changes.
What happens when someone reads the wrong version:
capabilities()and seefiles: falsefor Azure. Correct, and unchanged by this PR.Two of these strings are generated into
sandboxCapabilities.jsonand the zod schema, so the claim ships in the package and reaches anyone reading it in an editor.What was broken
Five statements, all asserting a cloud limitation where the limitation is ours:
sandbox.rs:172sandbox.ts:36-38sandbox.rs:865sandbox.rs:867sandbox.rs:914,:976The assertion message is the one with teeth. Whoever implements the Azure file operations will hit that failing test and be told the data plane cannot do the thing they just made it do — the misconception sits exactly where it will next mislead someone.
What I did
Reframed each to name the binding rather than the cloud, then regenerated the two published artifacts from the Rust source. The capability set still reports
filesandegressDenyfalse for Azure, which is correct for what a caller can reach today.Files touched
crates/alien-core/src/resources/sandbox.rs,packages/core/src/sandbox.ts, and the two regenerated files underpackages/core/src/generated/.How I tested
cargo test -p alien-core --lib sandbox— 34 pass. The assertions themselves are unchanged; only their messages moved.npx tsc --noEmitinpackages/core, andbiome checkon both touched TypeScript files.pnpm -C packages/core generaterather than editing the generated files, and confirmed both now carry the corrected text.One thing deliberately left alone:
.code(...)and.limits(...)do not reach the Azure provider, which starts every session from a fixed disk and size. That is a behaviour bug rather than a wording one and wants its own change.