Payload size isn't correct for some transactions

📢 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

[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.

[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 #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.