fix(env): one grant-reach check, size-scaled load timeouts on container sandboxes, and JSON state for services that export a file

[earakely-scale]

Summary

Three small core fixes, one commit each.

• One check for "this store's grants reach that sandbox". issues_grants_to(store, sandbox_type) replaces the supports_transfer_grants and grants_reach(...) pair at all five call sites, so a new caller can't check only one half. No behaviour change. _require_object_form keeps its two error messages.
• Load timeouts on container sandboxes. _staged_artifact_size ran stat through exec_script, which only VM sandboxes have. On a container sandbox (Modal) it raised, so every load there got the floor timeout whatever the payload's size. It now takes the size from the store's metadata for the artifact's object (get_object_metadata_at, which every store implements), as load_by_signed_url already does for plugin-deployed envs. The staged file is a byte-for-byte copy of that object. That removes the per-sandbox-kind stat (in the container on Modal, through docker on a VM-backed container sandbox, through the gateway's container on a VM), so a new sandbox backend can't break it again. A store that can't say still leaves the floor.
• JSON state for services that export a file. snapshot_agent_state and verify_universe_roundtrip assumed a v1 service's data/get answer starts with a DataPart. A service that exports a bundle of its database answers with a FilePart, so snapshot_agent_state skipped it with a warning and verify_universe_roundtrip failed. The new legacy_protocol.service_state returns the data when the answer is data, and otherwise reads the service's /export-state at the address its env card gives.

Testing

• Unit: tst/unit + protocol, 6330 passed. New tests cover:
  • a load whose RPC timeout follows the size its store holds for the payload;
  • a store that can't size the payload, with no metadata or a failing lookup, leaving the floor;
  • service_state for a data answer, a file-bundle answer and an empty answer;
  • snapshot_agent_state capturing a bundle-exporting service from /export-state.
• Integration: the items server fixture now serves /export-state, and with urn:agentenv:export-as-file/v1 enabled it answers data/get with a file bundle.
  • server_env_local_test (CI): a local server env's load measures the payload it staged, through the deploy's own handle and through a restored one. service_state reads the server's state as JSON in both answer modes.
  • server_env_modal_test: the same on Modal, when the resolved config reaches it. CI skips it.
• Mutant checks, all failing their tests:
  • service_state without its file fallback: 'FilePart' object has no attribute 'data';
  • on Modal, main's staged-size code: [None, None] == [31, 31].
• Plugin API: no break to the plugin surface.

End-to-end and chaos results are in a comment below.

🤖 Generated with Claude Code

[greptile-apps]

Export timeouts can drift

The new file-export fallback hardcodes timeout=60, while export_state has a separate 60-second default. The repository requires magic numbers to have descriptive names. Use a named timeout so these paths cannot drift when someone changes one of them. This requirement must be met before merging.

Rule Used: Store magic numbers as class or instance variables with descriptive names rather than using them inline in the code. (source)

Learned From
scaleapi/scaleapi#126388

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/agent_env/env/legacy_protocol.py
Line: 109

Comment:
**Export timeouts can drift**

The new file-export fallback hardcodes `timeout=60`, while `export_state` has a separate 60-second default. The repository requires magic numbers to have descriptive names. Use a named timeout so these paths cannot drift when someone changes one of them. This requirement must be met before merging.

**Rule Used:** Store magic numbers as class or instance variables with descriptive names rather than using them inline in the code. ([source](https://app.greptile.com/scale-ai/-/custom-context?memory=002e0051-41ad-46c1-9098-47433c580150))

**Learned From**
[scaleapi/scaleapi#126388](https://github.com/scaleapi/scaleapi/pull/126388)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[earakely-scale]

Named in f2bf992: EXPORT_STATE_TIMEOUT_SECONDS, the default of export_state and the timeout of the file-export fallback.

[earakely-scale]

End-to-end and chaos results (head 7e40368, with main merged)

Setup:

• Real env services on two remote sandbox providers (Modal containers, and a VM provider), against a dev deployment.
• The services are production-shaped MCP servers whose data/get exports a file bundle of their database.
• Each case was also run on main's code as a baseline.

case	Modal	VM provider	main, Modal
3.4 GB bundle loaded into a single-service env: staged size measured, timeout scaled	3,369,336,460 B → 3600 s (floor 900 s); load ok	same; load ok	"could not stat staged payload (… no attribute 'exec_script'); using the floor timeout"
the store's metadata lookup forced to fail	warning, floor timeout, load ok	same	–
a two-service env (calendar + chat, both answer data/get with a file): snapshot_agent_state capture and verify_universe_roundtrip export	both services captured and exported as JSON, equal table by table to /export-state (687,286 messages, 53,422 files, 985 channels, …)	same	both services skipped ('FilePart' object has no attribute 'data'); the export raises

The grant-reach refactor: re-running the file-delivery matrix from #61 on this head gave the same results as on #61. That covers grants, signed URL, staged on the agent, and a user-sim that can be given no URL.

The load rows were rerun on 7e40368, after the timeout moved to the store's metadata; the other rows ran on 3046e9a. The capture path didn't change between the two.

Teardown: every sandbox terminated, 0 failed.