-
Notifications
You must be signed in to change notification settings - Fork 46
Add per-session mutex locking to prevent race conditions #290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Commands executing concurrently within the same session could cause race conditions and interleaved output. This adds per-session mutexes using async-mutex to serialize execution within each session while preserving parallelism across different sessions. The withSession API enables atomic multi-command operations where the lock is held for the entire callback. Background streaming mode allows long-running processes like servers to release the lock after startup so other commands can proceed.
🦋 Changeset detectedLatest commit: 386ce36 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
🐳 Docker Images PublishedDefault (no Python): FROM cloudflare/sandbox:0.0.0-pr-290-2efc48eWith Python: FROM cloudflare/sandbox:0.0.0-pr-290-2efc48e-pythonWith OpenCode: FROM cloudflare/sandbox:0.0.0-pr-290-2efc48e-opencodeVersion: Use the |
Reduced unit test file from 303 to 197 lines by removing tests that checked timing measurements and implicit behaviors. Added E2E test for concurrent same-session access to the session isolation test file.
Add documentation explaining that commands within the same session execute serially while commands across different sessions run in parallel. This prevents race conditions and ensures predictable output within sessions. Key additions: - New "Concurrency and execution order" section explaining serial vs parallel execution - Examples demonstrating session-based parallelism for independent tasks - Best practices for choosing when to use same vs different sessions - Guidance on using multiple sessions for concurrent task execution Related to cloudflare/sandbox-sdk#290 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix setEnvVars to throw proper ServiceError with COMMAND_EXECUTION_ERROR code and CommandErrorContext details instead of generic Error. Expand deadlock warning to cover both withSession and executeInSession.
Clarify getOrCreateSession JSDoc to explain why callers must hold the session lock. Add cleanup of sessionLocks when session creation fails to prevent minor memory leaks.
GitManager.determineErrorCode() was returning custom strings like 'REPO_NOT_FOUND' that aren't in the ErrorCode enum. This caused withSession's error validation to reject them as unknown errors. Map all return values to proper ErrorCode constants.
b75c9ee to
386ce36
Compare
Commands executing concurrently within the same session could cause race conditions and interleaved output. This adds per-session mutexes using async-mutex to serialize execution within each session while preserving parallelism across different sessions.
The withSession API enables atomic multi-command operations where the lock is held for the entire callback. Background streaming mode allows long-running processes like servers to release the lock after startup so other commands can proceed.