OkHttpWebsocketSession does not complete the `closeReason` future when closing the websocket in absence of connectivity
Maintainers usually reply within 1 day
@jcovington16 is already working on this.
Since Mar 5, 2025.
- #9188 by @MohitAnuragi — closed without merging
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- kotlin
- Domain
- networking
Research direction
Start by reading OkHttpWebsocketSession and the RealWebSocket callbacks mentioned in the issue, focusing on how closeReason is completed by onClosing, onClosed, and onFailure. Reproduce the described disconnect-and-close sequence with ping-pong disabled; done means the coroutine awaiting closeReason terminates when the websocket is closed without connectivity.
Written by the indexing model from the issue text.
Description
Hello! 👋
I encountered this issue while doing some tests for the reliability of my ktor-based client application.
Reproduction steps
- Initialize a ktor application with websocket and where the built-in ping-pong mechanism is disabled.
- Launch 2 coroutines: Coroutine 1 communicates through websocket with a server external to the machine, Coroutine 2 awaits the completion of the
closeReasonFuture throughDefaultWebSocketSession.closeReason. - Disconnect the machine from the internet.
- Close the websocket.
Actual Behaviour
Coroutine 1 terminates while Coroutine 2 hangs forever.
Expected Behaviour
Coroutine 2 should also terminate, as closeReason should complete.
Analysis
Looking at the code, my understanding of the reason of this behaviour is that, in the OkHttpWebsocketSession class, the closeReason future is completed only in one of these 3 method: onClosing, onClosed, or onFailure.
onFailureis not called by theRealWebSocketimplementation when the connection drops because we disabled the built-in ping/pong mechanism in favour of a custom one.onClosingandonCloseare not called when the websocket is closed unless a control frame (OPCODE_CONTROL_CLOSE) is sent by the server, event that cannot happen under these conditions.
Additional Information
On the other hand, the CIO engine manages to complete the closeReason future under the same assumptions.
Question
Is this a design choice or just a bug due to a very niche condition?
- Dominant language
- Kotlin
- Stars
- 47.1k
- Forks
- 9.3k
- Avg merge
- 18h 18m
- Merged PRs (30d)
- 15
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lysine-dev/okhttp
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
lysine-dev/okhttp#9788 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
lysine-dev/okhttp#9761 · 3 comments ·
Maintainers usually reply within 1 day
-
Remove crossinline `addInterceptor` and `addNetworkInterceptor` overloadsPossibly taken @Amir-Golmoradi claimed this 6 days ago. Openenhancement
Difficulty 3/5 1-2 days Newbie friendliness 58/100
lysine-dev/okhttp#9779 · 1 comment ·
Maintainers usually reply within 1 day
-
HTTP/2 Data padding is not counted toward the connection flow-control window. This deadlocks connections with peers that pad.Possibly taken @Amir-Golmoradi claimed this 6 days ago. Openbug
Difficulty 3/5 1-2 days Newbie friendliness 67/100
lysine-dev/okhttp#9772 · 6 comments ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
lysine-dev/okhttp#9760 · 3 comments ·
Maintainers usually reply within 1 day
All issues in lysine-dev/okhttp
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
SLNE-Development/surf-chat#134 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100