No callbacks: no successful callbacks and no failed callbacks about okhttp

[yschimke]

There is not enough to go on. Try upgrading to 4.12 or even 5 alphas, and see if it still happens.

But closing as we can't help with this without a repro.

Maybe try a site like stack overflow.

[swankjesse]

Seeing secureConnectStart() but no secureConnectEnd() or connectFailed() tells us a lot about where it’s getting stuck. I wonder if the TLS handshake is broken in a way that’s causing them to not return.

Could you capture a thread dump of a process that has demonstrated this behavior? That’d be amazing to diagnose this further.

[Alexmego]

Seeing secureConnectStart() but no secureConnectEnd() or connectFailed() tells us a lot about where it’s getting stuck. I wonder if the TLS handshake is broken in a way that’s causing them to not return.

Could you capture a thread dump of a process that has demonstrated this behavior? That’d be amazing to diagnose this further.

In a release environment, the probability is too low to effectively capture the thread state and actively attempt to reproduce it, but it will not occur.

However, in this case, I can be certain that the timeout is invalid, there are no callbacks, and no Exception information. If a network request is initiated again, everything is normal again.

In my app, there are over 40000 requests, and 10-20 of them are in this situation. Although the impact is not significant, QA has caught abnormal phenomena, and R&D needs to provide a reasonable explanation for this. Currently, I have not made effective progress.

[Endeavour233]

secureConnectStart

The reason why connectTimeout does not work is that the time consumed in TLS handshake is not counted into connection time in the current implementation. And because the connection is not successfully established, readTimeout and writeTimeout don't take effect. Can you try to set callTimeout? I think your eventlistener would observe a canceled event then(though there was still no any callback - because when it's timeout, we just cancel the call, which would not trigger a CancelException in the case when the timeout is caused by a never-return method).

// RealCall.kt
  private val timeout =
    object : AsyncTimeout() {
      override fun timedOut() {
        [email protected]()
      }
    }.apply {
      timeout(client.callTimeoutMillis.toLong(), MILLISECONDS)
    }