fix(typescript): honor configured sandbox timeout in executeCode#3122
fix(typescript): honor configured sandbox timeout in executeCode#3122karimbaidar wants to merge 1 commit into
Conversation
executeCode hardcoded a 60s timeout and createSession never stored the session config, so SandboxConfig.timeoutSeconds was silently ignored. Persist the config per session and apply timeoutSeconds when executing code. Closes microsoft#3118 Signed-off-by: Karim Baidar <karimbaidar@gmail.com>
🤖 AI Agent: contributor-guide — View details
Welcome, and thank you for your detailed contribution! Great job on identifying and fixing the timeout enforcement issue while adding thorough test coverage. Before merging:
For guidance, see CONTRIBUTING.md. Let us know if you need help! |
🤖 AI Agent: breaking-change-detector — API Compatibility
API CompatibilityNo breaking changes detected. |
🤖 AI Agent: security-scanner — View details
No security issues found. |
🤖 AI Agent: docs-sync-checker — Docs Sync
Docs Sync
|
🤖 AI Agent: code-reviewer — View details
TL;DR: 0 blockers, 1 warning. Fix addresses a critical security issue effectively, but additional test coverage is recommended.
Action items:
Warnings:
|
🤖 AI Agent: test-generator — `agent-governance-typescript/src/sandbox.ts`
|
PR Review Summary
Verdict: AI review comments are untrusted advisory output. The summary reports workflow-generated completion status only, not model-authored pass/fail claims. |
|
Closing this in favor of #3120, which fixes the same issue in a better way. It runs |
Description
DockerSandboxProviderlets callers pass a customSandboxConfig.timeoutSeconds, but that value was silently ignored at execution time:createSession()applied the memory/CPU/network/env settings from the config but never stored the config object, so the per-session timeout was discarded after the container was created.executeCode()then ran the code with a hardcoded{ timeout: 60_000 }.As a result, the sandbox's execution-time limit was always 60s regardless of configuration. A caller who set
timeoutSeconds: 2got no enforcement below 60s, and a caller who set a larger value (e.g. 300) had work killed at 60s. Since the timeout is a sandbox containment control, this gave a false sense of control over how long agent-generated code can run.Fix
createSession()(asessionId -> SandboxConfigmap mirroring the existingcontainersmap).cfg.timeoutSeconds * 1000for thedocker exectimeout inexecuteCode(), falling back todefaultSandboxConfig()if a session somehow has no stored config.destroySession()so the new map does not leak.The change is non-breaking: the public method signatures are unchanged, and the default config keeps the previous 60s behavior.
Verification
tests/sandbox-timeout.test.ts, which stubschild_process(no Docker needed) and asserts the configured timeout reachesdocker exec. It fails against the old code (expected 2000, received 60000) and passes with the fix.sandboxtests pass;npm run buildandnpm run lintare clean.timeoutSeconds: 2, atime.sleep(5)snippet is now cut off at ~2s, whereas onmainit ran the full ~5s and printed its output.Type of Change
Package(s) Affected
Checklist
Attribution & Prior Art
Prior art / related projects (if any):
Not applicable — this wires an existing
SandboxConfigfield through to execution; no external code or design was adapted.AI Assistance
If AI tools materially shaped this change, briefly note what was used:
An AI coding assistant was used for drafting and test scaffolding. All output was reviewed and validated locally (unit test plus a live Docker reproduction) before submission.
IP, Patents, and Licensing
Related Issues
Closes #3118