fix: release lock before streaming to prevent orphan on client disconnect

[beran-t]

Summary

Fixes #213 — asyncio.Lock in messaging.py not released on client disconnect, causing cascading timeouts.

• Narrows the lock scope in ContextWebSocket.execute() so it only covers the prepare+send phase (Phase A), not result streaming (Phase B)
• Adds try/finally around streaming to clean up the _executions entry even if the generator is abandoned
• Uses dict.pop() instead of del for defensive cleanup

Root Cause

The lock was held for the entire async generator lifetime, including _wait_for_result() which blocks on await queue.get(). When a client disconnects (SDK timeout), Starlette abandons the generator while it's stuck at queue.get() — aclose() is never called because Starlette only detects disconnects when trying to write. The lock stays held until the kernel finishes internally, blocking all subsequent executions.

Why This Fix Is Safe

Streaming results (Phase B) doesn't need the lock because:

• Results are routed by unique message_id in _process_message() — no shared state during streaming
• The kernel serializes execution internally — the lock doesn't need to enforce this
• _global_env_vars (lazy init) and _cleanup_task (lifecycle management) are only accessed during Phase A

Reproduction & Verification

Tested on live E2B sandboxes with a custom code-interpreter-dev template built from this branch.

Before fix (stock code-interpreter template):

sleep(30) + 5s SDK timeout → print('hello') blocked 25.1s (orphaned lock)
sleep(60) + 3s timeout → 3 retries all timed out (cascade)

After fix (code-interpreter-dev template):

sleep(15) + 3s SDK timeout → print('hello') executes in 0.21s after kernel finishes
All 8 test cases pass: baseline, state persistence, env vars, error handling,
multiple contexts, JavaScript, lock-not-orphaned, no-cascade

Test plan

• Baseline execution: print('hello') works in <1s
• State persistence: variables survive across run_code calls
• Environment variables: envs parameter works correctly
• Error handling: ZeroDivisionError returned properly
• Multiple contexts: independent state
• JavaScript execution: console.log works
• Lock not orphaned: after timeout+disconnect, next execution succeeds once kernel is free (0.21s, not 25s)
• No cascade: retries after disconnect don't pile up behind each other

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 15ad5ab02e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Serialize env-var cleanup before allowing next execute

_cleanup_task is now created after the lock is released, so a concurrent call can enter execute() first, observe no pending cleanup, and queue its own code while the previous call’s per-request env_vars are still active. In practice, if request A sets env_vars and request B arrives before this assignment runs, B can execute with A’s environment, which is a regression from the old behavior that always waited for cleanup before starting the next execution.

Useful? React with 👍 / 👎.