Version 3.1.0 always claims that response body is empty

[jakoss]

📢 Describe the bug

After upgrading chucker to version 3.1.0 every single response shows 0 byte size and null body. In app everything works as expected. Downgrading to 3.0.1 fixes the issue

💣 To Reproduce

Do some api request. Go to chucker and click on it. Request is properly shown, but response body is "null". Response size is always 0 bytes"

🔧 Expected behavior

Body should be always properly shown.

📷 Screenshots

📱 Smartphone

• Device: Android Emulator
• OS: Android 9
• Lib version: 3.1.0

📄 Additional context

Whole request copied as text:

URL: <redacted>
Method: GET
Protocol: http/1.1
Status: Complete
Response: 200 OK
SSL: Yes

Request time: Fri Jan 24 10:58:58 GMT+01:00 2020
Response time: Fri Jan 24 10:58:58 GMT+01:00 2020
Duration: 67 ms

Request size: 0 B
Response size: 0 B
Total size: 0 B

---------- Request ----------

appInstallId: cc5a34e6-9ccf-46d4-9297-04f74a18355e
User-Agent: Android: 1.0.7-rc-dbg-dev (5) ; debug ; debuggableDev
Device-Name: AOSP On IA Emulator
HMAC: 6a2b11
Authorization: Bearer <token here>



---------- Response ----------

content-type: application/json; charset=utf-8
vary: Accept-Encoding
server: envoy
api-supported-versions: 1.0
date: Fri, 24 Jan 2020 09:58:56 GMT
x-envoy-upstream-service-time: 22

null

My chucker setup is fairly typical:

// setup collector
val chuckerCollector = ChuckerCollector(
            context = applicationContext,
            showNotification = false,
            retentionPeriod = RetentionManager.Period.ONE_DAY
        )

// adding interceptor
builder.addInterceptor(
            ChuckerInterceptor(
                context,
                collector = chuckerCollector
            )
        )

I have quite a few interceptors along the way. ChuckerInterceptor is almost last in the chain, after it there is only RetryInterceptor

[vbuberen]

Hey @NekroMancer
Thanks for reporting the issue.
The only change you had in your project is Chucker version upgrade?
Or something else has changed?

[vbuberen]

Ok, so I just checked updated version can confirm the issue, but I see it not with all requests.
Same thing with response content.

[jakoss]

I only bumped chucker update. And downgrading fixes the issue, so it must be version issue :)

[vbuberen]

Thanks for a really fast feedback.
We are going to release a hot-fix today in the evening.

@cortinico It is also might be the case for adding some other test requests into sample to catch such cases as well as add tests in code.

[jakoss]

Ok, now i see the response body, but it's showing -1 byte size:

But worse part is - it somehow alters response body in a way that crashes json converter along the way:

E/HomeViewModel$loadHomeData$$inlined$fetchData: java.lang.IllegalStateException: closed
        at okio.RealBufferedSource.read(RealBufferedSource.kt:184)
        at okio.ForwardingSource.read(ForwardingSource.kt:29)
        at retrofit2.OkHttpCall$ExceptionCatchingResponseBody$1.read(OkHttpCall.java:288)
        at okio.RealBufferedSource.request(RealBufferedSource.kt:207)
        at okio.RealBufferedSource.rangeEquals(RealBufferedSource.kt:491)
        at okio.RealBufferedSource.rangeEquals(RealBufferedSource.kt:128)
        at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:41)
        at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:27)
        at retrofit2.OkHttpCall.parseResponse(OkHttpCall.java:225)
        at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:121)
        at okhttp3.RealCall$AsyncCall.run(RealCall.kt:140)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

[vbuberen]

As to size, -1 is returned by OkHttp if size is unknown.

As to error - yeah, this happens with multiple interceptors.

I am still struggling with the issue, so we might not be able to release an update today.

P.S. thanks for a fast reply. Removed my request to you because also detected an issue with IllegalStateException

[jakoss]

Take your time, no pressure from me. Happy to test out new versions

[vbuberen]

@NekroMancer It is me again.
It seems that #206 solves the issue.
Could you check on your setup again?

[jakoss]

Ok, so on version 3.1.1:

Response size is still -1 on some bodies, but as i understand that means that size is unknown.
But, when i try to open a relatively big body (460 Kb) - Chucker crashes. Log below:

W/CursorWindow: Window is full: requested allocation 3195674 bytes, free space 2094099 bytes, window size 2097152 bytes
E/SQLiteQuery: exception: Row too big to fit into CursorWindow requiredPos=0, totalRows=1; query: SELECT * FROM transactions WHERE id = ?
    
    --------- beginning of crash
E/AndroidRuntime: FATAL EXCEPTION: arch_disk_io_1
    Process: pl.empik.music.dev, PID: 4869
    java.lang.RuntimeException: Exception while computing database live data.
        at androidx.room.RoomTrackingLiveData$1.run(RoomTrackingLiveData.java:92)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)
     Caused by: android.database.sqlite.SQLiteBlobTooBigException: Row too big to fit into CursorWindow requiredPos=0, totalRows=1
        at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow(Native Method)
        at android.database.sqlite.SQLiteConnection.executeForCursorWindow(SQLiteConnection.java:859)
        at android.database.sqlite.SQLiteSession.executeForCursorWindow(SQLiteSession.java:836)
        at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:62)
        at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:149)
        at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:137)
        at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:220)
        at android.database.AbstractCursor.moveToFirst(AbstractCursor.java:259)
        at com.chuckerteam.chucker.internal.data.room.HttpTransactionDao_Impl$7.call(HttpTransactionDao_Impl.java:574)
        at com.chuckerteam.chucker.internal.data.room.HttpTransactionDao_Impl$7.call(HttpTransactionDao_Impl.java:544)
        at androidx.room.RoomTrackingLiveData$1.run(RoomTrackingLiveData.java:90)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 
        at java.lang.Thread.run(Thread.java:764) 

[vbuberen]

Thanks.
Could I ask you to move this info into a new issue?
Also, is this response payload an image? Or just a big json?

[jakoss]

Sure I'll move it first thing tomorrow morning.

Just a big json

[jakoss]

Funny enough - i cannot reproduce this on my work computer. Maybe that issue was caused by some version upgrade issue. Anyhow - so far it's working great (apart of -1 response size, but that's pretty minor inconvenience)

[vbuberen]

Thanks for providing additional info. I wasn't able to reproduce as well by trying to get responses around 800 kb in size.
As to -1 - you check #209. Hope to deal with it soon after resolving other currently in-progress tasks on me, like search improvements.
Note, that original Chuck also has such issue with -1, so it is not something appeared just in Chucker.