Skip to content

Fix control mode: default to off and add fallback#6

Merged
vaurdan merged 2 commits intomainfrom
fix/control-mode-fallback
Feb 6, 2026
Merged

Fix control mode: default to off and add fallback#6
vaurdan merged 2 commits intomainfrom
fix/control-mode-fallback

Conversation

@vaurdan
Copy link
Contributor

@vaurdan vaurdan commented Feb 6, 2026

Summary

  • Default controlMode to false (opt-in) instead of true — servers that don't support the /control WebSocket endpoint no longer crash the SDK
  • Add graceful fallback in execFile — if a control connection fails, transparently falls back to regular per-command WebSocket execution

Context

Control mode was merged in #4 with controlMode: true as the default. This broke the sprite-env release pipeline because the example generator runs exec() against sprites that don't have control connection support. The WebSocket upgrade to /v1/sprites/{name}/control fails and the unhandled error crashes the process.

See: https://github.com/superfly/sprite-env/actions/runs/21733080553/job/62692018553

Test plan

  • Unit tests pass (npm run test:unit — 25 tests)
  • Control tests pass (node --test dist/control.test.ts — 8 tests)
  • After merging, update sprite-env submodule pointer for sdks/js and verify example generation succeeds

Re-add control connection support for multiplexed WebSocket operations,
with two key fixes over the original implementation:

- Default controlMode to false (opt-in) instead of true, so servers
  without /control endpoint support work without any changes
- Add graceful fallback in execFile: if control connection fails,
  transparently falls back to regular per-command WebSocket execution
@vaurdan vaurdan force-pushed the fix/control-mode-fallback branch from 9506118 to 4741bab Compare February 6, 2026 16:46
@vaurdan
Copy link
Contributor Author

vaurdan commented Feb 6, 2026

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

Pre-connection WebSocket errors were emitting on the EventEmitter
with no listener attached, crashing the Node.js process before the
try/catch fallback in execFile could catch the promise rejection.

Split error handling by connection phase: pre-connection errors only
reject the promise (caught by fallback), post-connection errors emit
on the EventEmitter for active operation listeners.
@vaurdan vaurdan merged commit 40e9e47 into main Feb 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

Comments