Payload size isn't correct for some transactions

[vbuberen]

📢 Describe the bug

Some transactions show payload size as -1. It is totally fine, since OkHttp returns this value in case the size is unknown. However, when I wanted to handle this value in Chucker UI I decided to check what other network interceptors show and found out that Stetho show sizes for transactions, which show -1 in Chucker.

🔧 Expected behavior

Transactions show actual size instead of -1.

📷 Screenshots

[vbuberen]

After some basic investigation found out that Chucker solely relies on contentLength value in response to show the size, while Stetho does some calculations itself in case response headers have no contentLength value. Requests from the screenshot in my bug report are exactly such items with no mentioned value in their response.

So Chucker needs to implement the same mechanism.

[MiSikora]

This could be fixed after merging #267. We would have to keep counting the bytes in TeeSource and report it back in the callback.

[MiSikora]

I was thinking about this feature lately and see couple of things that could be done.

• If Content-Length is available Chucker could just use this value to determine the size of the response.
• If Content-Length is not available Chucker could wait for the response to be read in a TeeSource and be informed about bytes read once upstream is depleted. The problem occurs if the consumer does not read bytes fully like reported in Chucker does not recognise partially read responses #287. In this case there is no way of knowing what would be the size of the response.
• Chucker could display amount of data that was downloaded by the user and the size of the response if it is available (either form Content-Length or from TeeSource if exhausted). It would require some UI changes on most of the screens.
• Chucker could show gradual changes of downloaded data. So while bytes are being read from an upstream it would display progressively 8 kB, 16 kB, 24 kB and so on. Not really sure if there is a need for this. It would also require some UI changes.

[vbuberen]

Moving further, so we could release 3.2.0

@MiSikora as to your ideas - agree on first 3 points, but the last one with progressive update of the request size is an overengineering, which won't bring much value to our users.

[MiSikora]

Yes, I think so as well. Just wanted to propose it in case you find it valuable.

[cortinico]

Agree on the first 3 points as well. On a side note I was also wondering if we should show the Content-Length aside the size.

I actually think it might be valuable for the user to see Content-Leght: -1 next to Size: xxx B to realise that the Content-Leght was missing.

[vbuberen]

We could show Unknown instead of -1 to be more specific or just drop the line with Content-Lenght at all from transaction description in such cases.

[cortinico]

We could show Unknown instead of -1 to be more specific

++

[aldoKelvianto]

Hi, I would like to bump this issue because it still occurs on my project.

I've been using 3.1.2 and 3.2.0 release. It still produces incorrect content-size, while Chuck shows the correct content-size.

Chucker

Chuck

[vbuberen]

Hi @aldoKelvianto
Thanks for reporting. The fix for this issue wasn't deployed yet, so there is nothing to bump :)

However, it is strange that Chuck shows the size while Chucker not.
Are these transactions have no Content-Length header?

[cortinico]

Thanks for reporting @aldoKelvianto

It still produces incorrect content-size, while Chuck shows the correct content-size.

Can you please share the .addInterceptor(...) configuration you're using? Are you applying both Chuck and Chucker together? Do you have other interceptors? If yes, what's the order?

[aldoKelvianto]

However, it is strange that Chuck shows the size while Chucker not.
Are these transactions have no Content-Length header?

You guess it correctly. There's no Content-Length header in the API response. In Chucker's sample App, the responses contain content-length.

However, in my project, the response doesn't have content-length

However, it is strange that Chuck shows the size while Chucker not.

Yes, this surprises me as well 😄

[aldoKelvianto]

Thanks for reporting @aldoKelvianto
It still produces incorrect content-size, while Chuck shows the correct content-size.
Can you please share the .addInterceptor(...) configuration you're using? Are you applying both Chuck and Chucker together? Do you have other interceptors? If yes, what's the order?

You're welcome!

Sure, however, I don't think you'll find it interesting.

private fun createOkHttpClient(): OkHttpClient =
    OkHttpClient.Builder().apply {
        cache(createOkHttpCache())
        addInterceptor(ChuckerInterceptor(context))
        connectTimeout(CONNECT_TIMEOUT, TimeUnit.SECONDS)
        readTimeout(READ_TIMEOUT, TimeUnit.SECONDS)
    }.build()

I don't use other interceptors. I replace ChuckInterceptor with ChuckerInterceptor.

[cortinico]

You guess it correctly. There's no Content-Length header in the API response.

Great. As discussed above we're probably going to decouple the Content-Length to the actual payload size in two different fields.