It now tracks inbound requests that fail with an IOException.
Also add a fix for the bug where we'd send 'END OF STREAM' on a stream
that we'd previously canceled, which raced with the 'RST STREAM' and led
to flakiness.
Before we ship the new API in RecordedRequest we should go over the
other cases where inbound HTTP requests fail and make sure they
get reported through this channel.
Closes: https://github.com/square/okhttp/issues/5388
* Name tasks only in TaskRunner
Naming queues seemed good initially, but the names are mostly
mutually-redundant with task names.
This PR reduces debug information when a queue is still busy
when the test completes. I have a fix for that in a follow-up
change.
* Update okhttp/src/main/java/okhttp3/internal/ws/RealWebSocket.kt
Co-Authored-By: Yuri Schimke <yuri@schimke.ee>
We used to do this lazily because OkHttpClient instances were
somewhat heavy: each standalone instance held its own
ExecutorService for the connection pool.
Now that we have TaskRunner each instance is much more
lightweight and the drawbacks of creating instances eagerly
is negligible.
Shutting down queues makes it easier to implement HTTP/2
shutdown because we can enqueue everywhere and centralize
the logic that decides whether we're shutdown or not.
Use this new functionality to implement HTTP/2 on task queues.
It's mostly a drop-in replacement, though opting-into cancel
looks like a mistake when it's what we do most of the time.
When testing this the OkHttpClientTestRule was failing because
tasks were incomplete. I was puzzled by this until I realized
that the OkHttpClientTestRule performs that validation before
we stop the MockWebServer. I changed MockWebServer to have its
own TaskRunner and that made the problem go away.
* OkHttpClientTestRule check connectionCount instead of idle
Clients should be clean after use, not just from idle connections.
* Abandon unclean clients
* Simplify logic
I'm hoping to follow this up with a change so that this rule can also do the
uncaught exception handling that we're currently doing elsewhere.
See https://github.com/square/okhttp/issues/4894
When connections are established concurrently, verify() sometimes throws a `java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0` because of unsynchronized access to the `calls` list.
This will help prevent regressions and point to the leaking test, rather than to a later test that happens to checks for leaks. The change is applied to all tests that have an OkHttpClient member variable.