-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential failure on CallServerInterceptor if writeRequestHeader fails #8283
Comments
gdrehmer
changed the title
Potential failure
Potential failure on CallServerInterceptor if writeRequestHeader fails
Mar 14, 2024
Probably a dupe of #6853 I'll take a look again on the weekend. |
Any updates on this topic? I also receive this error with almost the same stacktrace:
|
The same for me. I also receive this error. How I can fix this? |
Any solution, we are experiencing this as well. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unfortunately this bug is hard to replicate and to create a failing test.
But I hope it still gets attention.
We've noticed that there is a big number of crashes in our customer base after upgrading from OkHttp 4.9.3 to version 4.12.0, as per stacktrace below.
We've also noticed a change in 4.11 could be related to that:
e46a200
It seems that a change has been introduced in
CallServerInterceptor
which moved theexchange.write*
operations into atry/catch
block (I suppose by design, to fix the issue as referenced in the commit).However, the effect of that could be that the following block, the
exchange.readResponseHeaders
might be executed withstate
set to0
(IDLE, not initalised), if the previousexchange.writeRequestHeaders(request)
operation failed for any reason apart fromConnectionShutdownException
. ThereadResponseHeaders
has a guard statement which would throw an exception ifstate == 0
.I couldn't find a way which could cause the
exchange.writeRequestHeaders
call to raise an exception, but we are observing many cases (it is our top crash, affecting thousands of customers in a couple of days after rollout).It is important to note that we also updated from Okio 3.0.0 to 3.7.0 in the same release.
Stacktrace:
The text was updated successfully, but these errors were encountered: