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
|
|
||
|
|
||
| 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?
There was a problem hiding this comment.
Agreed. Better to retry by default, and the user can just set a retry policy with 0 retries if they don't want it.
There was a problem hiding this comment.
In the context of a sandbox, most commands are deterministic (writing to a file for instance) and seeing a timeout once usually means you'll see it again.
| 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=...,
)
There was a problem hiding this comment.
Will do! Making execution_id=workflow_run_id+activity_id so it can work across continue as new
# Conflicts: # temporalio/contrib/strands/_plugin.py
Summary
Testing