Calling `enqueue()` from OkHttp’s Dispatcher shouldn’t count against thread limits

[swankjesse]

With coroutines it’s pretty common to use Call.enqueue() in the implementation of an Authenticator or Interceptor.

This ends badly because if the Dispatcher’s is at its configured limit there’s no thread to serve the enqueued call, and the overall network stack can deadlock!

We’ve documented this a bit, but it’s still a hazard. Especially when features like suspend on Wire gRPC and Retrofit make it very easy to use a background thread without even knowing it.

Rather than broadly warning everyone of the dangers of this antipattern, we should just make it so enqueued calls made on OkHttp’s Dispatcher thread don’t count against dispatcher limits. Those calls should be performed immediately. This will avoid deadlocks and remove a footgun from our API.

[yschimke]

Is there a good pathological case, or common case such as Retrofit to test against?

I'll take a look at this on the weekend, mainly playing around. Not licking the cookie, more interested to help get a POC up to jam on, and hopefully make it into the next release.

[yschimke]

Current approach uses a Call.Factory attached to the interceptor.

Next approach I'll try is checking if the thread is owned by the current clients Dispatcher, and if so do the same.