You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Handle server-initiated WebSocket closes without reconnecting #103
A server-initiated WebSocket close does not reliably notify onDisconnected, and non-1000 closes are treated as reconnectable. Flux STT closes after CloseStream with no status (observed as 1005), so applications that wait for the server close can hang or reconnect instead of terminating.
Affected version
0.10.0
Evidence
src/main/java/com/deepgram/core/ReconnectingWebSocketListener.java implements onClosed(...) but not onClosing(...); it calls scheduleReconnect() for every code other than 1000. The class is Fern-generated but temporarily frozen for existing reconnect fixes.
Expected behavior
A server close should result in one onDisconnected callback and should not reconnect when the protocol session has ended.
Acceptance criteria
Server-initiated close reaches the public onDisconnected handler without an explicit client disconnect().
A no-status/1005 close after Flux CloseStream does not reconnect.
Reconnect behavior remains available for actual transport failures.
Add a MockWebServer regression test.
Preserve the .fernignore freeze and report the generator gap upstream.
Validated against production on 2026-09-14. Flux invokes onClosing with code 1005 after CloseStream. Echoing that reserved code causes OkHttp to throw IllegalArgumentException, which routes to failure/reconnect. The proposed fix acknowledges 1005 with a valid 1000 close; the live probe then received one onDisconnected callback (code=1005) and observed no reconnect.
The fix now lives in #110, which supersedes the closed #105. #110 retains the Listen V2 CloseStream/no-status-close handling and will close this issue when it merges.
Resolved by #110 (merged 2026-09-17). The current reconnect listener acknowledges peer closes, maps the local-only 1005 sentinel to wire-valid 1000, delivers the normal disconnected callback, and the Listen V2 policy suppresses reconnect only after that socket successfully sent CloseStream. #110 includes regression coverage for peer-close, accepted/rejected CloseStream, and terminal-state reset behavior.
Activity
GregHolmes commentedon Sep 14, 2026
Validated against production on 2026-09-14. Flux invokes
onClosingwith code1005afterCloseStream. Echoing that reserved code causes OkHttp to throwIllegalArgumentException, which routes to failure/reconnect. The proposed fix acknowledges 1005 with a valid1000close; the live probe then received oneonDisconnectedcallback (code=1005) and observed no reconnect.GregHolmes commentedon Sep 17, 2026
The fix now lives in #110, which supersedes the closed #105. #110 retains the Listen V2 CloseStream/no-status-close handling and will close this issue when it merges.
GregHolmes commentedon Oct 2, 2026
Resolved by #110 (merged 2026-09-17). The current reconnect listener acknowledges peer closes, maps the local-only 1005 sentinel to wire-valid 1000, delivers the normal disconnected callback, and the Listen V2 policy suppresses reconnect only after that socket successfully sent CloseStream. #110 includes regression coverage for peer-close, accepted/rejected CloseStream, and terminal-state reset behavior.