mirror of
https://github.com/kvcache-ai/AgentENV.git
synced 2026-11-05 01:17:36 +00:00
[PR #258] [CLOSED] fix(api): support official E2B SDK volume mounts #299
Labels
No labels
bug
documentation
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
kvcache-ai/AgentENV#299
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/kvcache-ai/AgentENV/pull/258
Author: @yingdi-shan
Created: 9/7/2026
Status: ❌ Closed
Base:
main← Head:fix/e2b-volume-compat📝 Commits (2)
0bccee8fix(api): support E2B SDK volume mountsfc57306fix(api): preserve legacy volume mount requests📊 Changes
10 files changed (+464 additions, -65 deletions)
View changed files
📝
crates/aenv/src/client/sandboxes.rs(+33 -6)📝
docs/src/concepts/volumes.md(+15 -3)📝
scripts/tests/e2e/e2b_ts_sdk_compat.ts(+43 -3)📝
scripts/tests/e2e/suites/09_e2b_compat.sh(+5 -4)📝
scripts/tests/e2e/suites/15_volume.sh(+2 -1)📝
scripts/tests/e2e/suites/16_volume_randomized.sh(+3 -2)📝
src/api/generated/src/models.rs(+217 -28)📝
src/api/impls/sandbox.rs(+96 -5)📝
src/api/openapi.yml(+30 -3)📝
src/api/proxy.rs(+20 -10)📄 Description
What
SandboxVolumeMount[]wire representation for responses and new clients while accepting legacy map requestse2b@2.38.0Why
The official TypeScript SDK serializes
volumeMountsas an array of{name, path}objects. AgentENV expected a map, so otherwise valid SDK sandbox creation failed with HTTP 422 after volume control-plane calls succeeded.Related issue
Closes #257
Scope and non-goals
This PR fixes SDK-managed volume mounting and documents the supported boundary. It does not add E2B's standalone
/volumecontentdata plane, so AgentENV does not return a volume token or domain. In particular, it does not return an empty, placeholder, or API-key-derived token. Volume contents remain accessible through a sandbox mount.Volume.list()sends no pagination parameters and does not consumeX-Next-Token. AgentENV intentionally keeps its existing bounded default page of 100 volumes instead of returning the full catalog; the SDK therefore sees the first page only.Design and behavior changes
The OpenAPI response schema uses an array of
SandboxVolumeMountobjects. Request models use an untaggedoneOfthat accepts either that array or the legacy path-to-volume map. API handlers convert both forms to the existing internal mount map before volume reservation and convert stored maps back to deterministically sorted arrays in responses. Duplicate array paths are rejected with HTTP 400 before any volume is reserved.The E2E test uses the same SDK path as applications:
Volume.create,Volume.getInfo,Volume.connect,Volume.list, andSandbox.createwith the connected volume. It writes and reads a marker through the guest mount to verify the mount is usable.Compatibility and operations
volumeMountsrequests accept both the AgentENV map and official E2B array representations. Responses and the bundled client use the E2B array. Generated server models were regenerated.{name, path}[]. Rolling back requires new clients to restore the map payload.e2b@2.38.0as a test-only dependency.Validation
make fmtmake clippymake test-unitmaketargetCommands and results:
All listed commands passed. The SDK E2E suite passed all 8 checks, and the legacy-map volume lifecycle suite passed all 39 checks while validating array responses. An initial SDK E2E retry timed out during base-template setup after repeated GHCR EOFs; the same command passed once the registry recovered.
Skipped checks and reasons:
make -C services test: noservices/changes.Risks and reviewer notes
The request compatibility model is intentionally limited to the two documented representations. Responses always use the E2B array, and the core volume reservation, snapshot, and storage paths remain unchanged behind the API conversion.
E2B's volume token is used only by its separate volume-content client as a Bearer token for
/volumecontent/{volumeID}requests. Sandbox mount serialization uses the volume name and does not consume that token, which is why mounted access is supported without inventing data-plane credentials.Checklist
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.