Skip to content

Improve OpenCode bridge startup reliability and error handling - #9

Merged
marchingphoenix merged 1 commit into
mainfrom
claude/fix-chat-opencode-connection-2JJ2Y
Feb 13, 2026
Merged

Improve OpenCode bridge startup reliability and error handling#9
marchingphoenix merged 1 commit into
mainfrom
claude/fix-chat-opencode-connection-2JJ2Y

Conversation

@marchingphoenix

Copy link
Copy Markdown
Owner

Summary

This PR enhances the OpenCode bridge's startup robustness and error handling by adding a readiness timeout, improving stderr classification, and implementing a connection timeout in the chat participant. These changes ensure the bridge properly waits for process initialization and gracefully handles communication failures.

Key Changes

Bridge Startup & Readiness

  • Added waitForReady() method that waits up to 5 seconds for the spawned process to either stabilize or fail, preventing callers from seeing state="idle" when the process is about to crash
  • Introduced SPAWN_READY_TIMEOUT_MS constant (5000ms) to define the readiness window
  • Added startBridge() test helper that advances fake timers to simulate the readiness timeout

Stderr Handling Improvements

  • Refactored handleStderr() to distinguish between genuine errors and informational messages
  • Added isStderrError() heuristic that identifies error patterns: "Error:", "ERROR:", "FATAL:", "panic:", "Traceback" (case-insensitive)
  • Error-like lines fire error events; other stderr output fires status events with agent: "system" to inform users without terminating responses
  • Empty/whitespace-only stderr lines are now ignored

Docker Exec Flag

  • Added -i (interactive) flag to docker exec command in in-container execution mode
  • Ensured -i is placed after exec but before the container ID

Chat Participant Connection Timeout

  • Implemented 30-second connection timeout in handleAsk() that triggers if no events arrive from the bridge
  • Timeout is reset on each event, indicating the process is responsive
  • Listeners are now registered before sending the prompt to avoid missing early events
  • Provides user-friendly error message when timeout occurs

Test Coverage

  • Added afterEach() hook to restore real timers after each test
  • Added test for early resolution when process errors during startup
  • Added tests for -i flag placement in docker exec arguments
  • Added comprehensive stderr handling tests covering error patterns, status messages, and empty lines
  • Updated all existing tests to use startBridge() helper for consistent timer handling

Implementation Details

  • Uses fake timers in tests to control async timing without delays
  • The waitForReady() promise settles either via state change listener (error/stopped) or timeout expiration
  • Stderr classification uses a regex pattern to catch common error indicators while allowing informational output through
  • Connection timeout in chat participant is independent of bridge readiness, providing an additional safety net for hung processes

Version

Bumped to v0.1.4

https://claude.ai/code/session_01D12992HnEWn4Jh3iX9SFRe

…ker stdin, and timeout

- Register event listeners BEFORE sendPrompt() in handleAsk to prevent
  missing fast responses or errors (race condition)
- Add 30-second connection timeout so the chat doesn't hang indefinitely
  when the process starts but never responds
- Stop treating all stderr output as fatal errors — only lines matching
  error patterns (Error:, FATAL:, panic:, Traceback) fire error events;
  informational stderr is surfaced as status events instead
- Add -i flag to docker exec in in-container mode so stdin is forwarded
  to the container process (required for sending commands)
- Add waitForReady() to bridge.start() so callers know when the process
  has either stabilized or failed during startup
- Bump version to 0.1.4

https://claude.ai/code/session_01D12992HnEWn4Jh3iX9SFRe
@marchingphoenix
marchingphoenix merged commit 3cfb646 into main Feb 13, 2026
4 checks passed
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.

2 participants