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
It seems that a change has been introduced in CallServerInterceptor which moved the exchange.write* operations into a try/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 with state set to 0 (IDLE, not initalised), if the previous exchange.writeRequestHeaders(request) operation failed for any reason apart from ConnectionShutdownException. The readResponseHeaders has a guard statement which would throw an exception if state == 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:
Exception java.lang.IllegalStateException: state: 0
at okhttp3.internal.http1.Http1ExchangeCodec.readResponseHeaders (Http1ExchangeCodec.kt)
at okhttp3.internal.connection.Exchange.readResponseHeaders (Exchange.kt)
at okhttp3.internal.http.CallServerInterceptor.intercept (CallServerInterceptor.kt)
at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.kt)
at okhttp3.internal.connection.ConnectInterceptor.intercept (ConnectInterceptor.kt)
at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.kt)
at okhttp3.internal.cache.CacheInterceptor.intercept (CacheInterceptor.kt)
at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.kt)
at okhttp3.internal.http.BridgeInterceptor.intercept (BridgeInterceptor.kt)
at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.kt)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept (RetryAndFollowUpInterceptor.kt)
at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.kt)
at my.company.SomeInterceptor
(...)
at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.kt)
at okhttp3.internal.connection.RealCall.getREsponseWithInterceptorChain$okhttp (RealCall.kt)
at okhttp3.internal.connection.RealCall$AsyncCall.run (RealCall.kt)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:644)
at java.lang.Thread.run (Thread.java:1012)
The text was updated successfully, but these errors were encountered:
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: