Add durable Strands sandbox support - #1768
Conversation
A timeout is the deterministic outcome the caller's own `timeout` argument asked for, so retrying just re-runs the same hanging command. Under Temporal's unlimited-attempt default this meant SandboxTimeoutError never reached workflow code and the agent could never observe the timeout and adapt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every built-in Strands sandbox raises a plain FileNotFoundError from read/write/remove — only list_files raises the SandboxPathNotFoundError subclass — so the old handlers were dead code and a missing path retried forever instead of reaching workflow code. Catch the documented base class instead, and carry the sandbox's own message through so a timeout reports the duration it actually enforced rather than the one the caller requested. Also fix the DockerSandbox import in the README, which is not re-exported from strands.sandbox, and note that the sandbox cache is per worker process. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Codex Review: Didn't find any major issues. Swish! 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". |
| # workflow | ||
| agent = TemporalAgent( | ||
| sandbox=TemporalSandbox( | ||
| "build", |
There was a problem hiding this comment.
Now that we are using SandboxWorkflowContext do we need the name?
| "build", |
There was a problem hiding this comment.
The name selects the corresponding sandbox defined in StrandsPlugin(sandboxes=...), whereas the context contains the Workflow ID.
There was a problem hiding this comment.
Could the factory function handle all sandbox retrievals instead of name map?
TemporalAgent(
sandbox=TemporalSandbox(start_to_close_timeout=timedelta(minutes=5))
)
...
plugins=[StrandsPlugin(sandboxes=build_sandbox)]There was a problem hiding this comment.
The name map is good because it's what we already do for MCP, and it allows us to have multiple sandboxes in the same environment.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 18d709b210
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| value: dict[str, Any] | ||
|
|
||
|
|
||
| class _SandboxRecord: |
There was a problem hiding this comment.
Can the cache be replaced with a call to the user-provided factory for every activity? The factory can then resolve the correct sandbox using the current context and implement caching appropriate to its backend. This would simplify the lifecycle and cancellation logic, and keep caching policy with the component that understands sandbox identity and cleanup.
There was a problem hiding this comment.
I like the idea in principle, but if you were making millions of tool calls you'd have millions of factory calls. It's possible that factory calls are expensive, which could force users to have to implement some type of caching mechanism in their factories to avoid the cost.
xumaple
left a comment
There was a problem hiding this comment.
Overall looks good but provided some comments
| self, operation: str, input: Any, *, result_type: type | None = None | ||
| ) -> Any: | ||
| input.sandbox_name = self._name | ||
| input.first_execution_run_id = workflow.info().first_execution_run_id |
There was a problem hiding this comment.
Using first_execution_run_id here is operationally convenient, but it means the sandbox isolation key is not entirely derived from trusted Activity metadata. Arbitrary workflow code on the same task queue can invoke the named Activity and choose a first-execution Run ID. If workflow IDs are reused, or if multiple trust domains share workers, that can potentially reconnect to another chain’s backing environment.
There was a problem hiding this comment.
This should at least be documented even if we consider workflow code to be trusted.
| def _has_record(self, key: _SandboxKey, record: _SandboxRecord) -> bool: | ||
| return self._records.get(key) is record | ||
|
|
||
| def _evict(self, key: _SandboxKey, record: _SandboxRecord) -> None: |
There was a problem hiding this comment.
Eviction removes _SandboxRecord, but it does not close the resulting sandbox or adapter. aclose() also awaits creation
and then discards the object.
That may be harmless for DockerSandbox if it is only a lightweight identifier, but other implementations may own HTTP
clients, WebSockets, subprocess handles, tunnels, or leases. How are we planning to handle that?
|
|
||
|
|
||
| def _timeout_error(err: SandboxTimeoutError, timeout: float | None) -> ApplicationError: | ||
| # A timeout is the deterministic outcome the caller asked for, so retrying |
There was a problem hiding this comment.
A timeout is the deterministic outcome the caller asked for
It is? Isn't timeout the definition of something we should retry?
| ExecutionResult, | ||
| FileInfo, | ||
| Sandbox, | ||
| StreamChunk, |
There was a problem hiding this comment.
Raw StreamChunk values lack:
- sandbox name;
- workflow operation/execution ID;
- Activity attempt;
- chunk sequence;
- command versus code execution.
That makes a shared topic difficult to consume correctly. “Use different topics” pushes correlation onto callers and
becomes awkward for concurrent agent tool calls.
I would publish an envelope such as:
SandboxStreamEvent(
sandbox_name=...,
execution_id=...,
attempt=...,
sequence=...,
chunk=...,
)
| All arguments and results cross Temporal's payload boundary and enter workflow | ||
| history. Keep command output and files within the server's configured payload | ||
| size limits; use external storage for large artifacts. In particular, `env` | ||
| values are recorded in history and must not contain secrets. |
There was a problem hiding this comment.
this suggests that we should maybe use a secret reference system the same way that we did for openai sandboxing?
| activities do not construct a `WorkflowStreamClient` and the workflow does not | ||
| need to host a `WorkflowStream`. | ||
|
|
||
| All arguments and results cross Temporal's payload boundary and enter workflow |
There was a problem hiding this comment.
I don't like when we put things like "cross Temporal's activity boundary" or the like into docs/readmes. llms love to use this type of language but for users who are not super familiar with temporal, this can be very confusing. Prefer pointing to things being "serialized into workflow history" I think that makes a lot more sense for a wider audience.
Summary
Testing