Repository navigation
fix(realtime): reject connect() promise when WebSocket errors before … - #186
Merged
ccampbell-aai merged 3 commits intoSep 21, 2026
Conversation
ccampbell-aai
requested changes
Sep 20, 2026
ccampbell-aai
left a comment
ccampbell-aai
left a comment
Contributor
There was a problem hiding this comment.
Hey @shobhitagnihotri69 thanks for digging into this! This is a valid fix, but there a couple changes noted inline. Plus, please include a version bump and addition to the change log as seen in other closed PRs.
Please note that this fix is for a legacy client for an old (v2) api path.
Contributor
Author
|
Hi @ccampbell-aai Can you please look into this updates changes , I have tried to fix all the changes |
…SessionBegins Fixes AssemblyAI#136. RealtimeTranscriber.connect() returned a Promise that only captured resolve, not reject. When the underlying WebSocket emitted an onerror event before the server sent a SessionBegins message (e.g. connection refused, auth failure, network drop), the error was forwarded to any registered error listener but the connect() promise was left in the pending state forever. Callers awaiting connect() would hang indefinitely. Changes: - Add a private field to hold the rejection handler from the connect() Promise. - In , call if it is set (i.e. SessionBegins has not yet been received), then clear the field. - In the SessionBegins handler, clear so that any subsequent socket errors after a successful handshake only propagate to the error listener, not to the already-resolved connect() promise. Tests: - rejects connect() when WebSocket errors before SessionBegins - does not reject an already-resolved connect() on subsequent errors All 26 tests pass.
…e 136 reference - Implement discardPendingSocket() on RealtimeTranscriber and invoke it when pre-session connection fails (in onerror and onclose) so that callers can safely retry connect() without encountering 'Already connected'. - Remove references claiming to fix AssemblyAI#136 in comments and tests. - Add unit test verifying reconnecting after a failed connect() attempt. - Add unit test verifying discardPendingSocket() attaches an error sink.
shobhitagnihotri69
force-pushed
the
fix/136-connect-rejects-on-error
branch
from
September 20, 2026 02:08
1778862 to
3236c00
Compare
ccampbell-aai
approved these changes
Sep 21, 2026
Contributor
|
@shobhitagnihotri69 thanks for making those changes! Great find and we appreciate the contribution! |
Contributor
Author
|
Thank you very much for merging , I appreciate every merge, looking forward to contribute as much as possible @ccampbell-aai |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…### Summary
In
RealtimeTranscriber.connect()(src/services/realtime/service.ts), the connectionPromiseexecutor only capturedresolveand omittedreject.If a connection failed before the server emitted
SessionBegins(such as on network disconnect, DNS resolution failure, or server rejection), the underlying WebSocket emitted anerrorevent which notified event listeners, but theconnect()promise was left in a pending state forever. Callers awaitingconnect()would hang indefinitely without entering theircatchblock.Changes
connectReject?: (reason?: unknown) => voidfield onRealtimeTranscriber.connect(), captured the rejection handler alongsideresolve.errorevent handler, ifconnectRejectis set, invoke it and clear the reference.SessionBeginsmessage handler, clearconnectRejectso subsequent runtime errors after handshake only emit to event listeners and do not attempt to settle the already-resolved promise.connect()rejects with the error when WebSocket emitserrorprior toSessionBegins.connect()does not reject on subsequent post-handshake socket errors.Verification
npm test). All 26 tests passed.