FileNotFoundException drops the request

[CodeBreak524]

After performing one of the requests in my app I receive that kind of error which results in failed request:

java.io.FileNotFoundException: /data/user/0/app.name.dev/cache/chucker-21 (No such file or directory)
        at java.io.FileOutputStream.open0(Native Method)
        at java.io.FileOutputStream.open(FileOutputStream.java:308)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:238)
        at okio.Okio__JvmOkioKt.sink(JvmOkio.kt:170)
        at okio.Okio.sink(Unknown Source:1)
        at okio.Okio__JvmOkioKt.sink$default(JvmOkio.kt:170)
        at okio.Okio.sink$default(Unknown Source:1)
        at okio.Okio.sink(Unknown Source:3)
        at com.chuckerteam.chucker.internal.support.TeeSource.<init>(TeeSource.kt:27)
        at com.chuckerteam.chucker.api.ChuckerInterceptor.multiCastResponseBody(ChuckerInterceptor.kt:184)
        at com.chuckerteam.chucker.api.ChuckerInterceptor.intercept(ChuckerInterceptor.kt:93)

Repeating the same request doesn't solve this problem, but performing a different request does.

💣 Steps to reproduce

It happens after giving the control off app to another third-party library. I cannot tell you more concrete info because I really don't know what happens inside this library. Maybe it clears all caches of app which then results in Chucker error.

🔧 Expected behavior

Anyway it seems that dropping the request with internal error is not the best option. A warning should be enough even though the request wouldn't be logged.

Tech info - different devices, different OS versions

[MiSikora]

I considered whether this should be wrapped in a try/catch block but decided against it while implementing response handling.

chucker/library/src/main/java/com/chuckerteam/chucker/internal/support/TeeSource.kt

Line 27 in a6ed2d4

private val sideStream = Okio.buffer(Okio.sink(sideChannel))

In my opinion, the issue should be reported to this third-party vendor as a bug. However, I also understand where are you coming from. We could ignore the processing body of requests which fail to create a file.

@vbuberen @cortinico what do you think? Do you see a need for some special message for requests that fail for this reason? Personally I don't think so as from my perspective it is the same as any IO failure during writes or reads from a file. On the other hand, it might be harder in the future to analyze similar issues. Maybe there should be some UI to indicate this type of errors?

[cortinico]

In my opinion, the issue should be reported to this third-party vendor as a bug. However, I also understand where are you coming from. We could ignore the processing body of requests which fail to create a file.

Ideally that should be the right thing to do.

On the other hand, it might be harder in the future to analyze similar issues. Maybe there should be some UI to indicate this type of errors?

How about printing the stacktrace with some extra message? That will help at least debugging once we get users reporting those kind of issues.

[CodeBreak524]

Guys, I tried 3.3.0-SNAPSHOT version and haven't received FileNotFoundException again. But now I'm receiving another exception in the same place:

 java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively0(Native Method)
        at java.io.UnixFileSystem.createFileExclusively(UnixFileSystem.java:281)
        at java.io.File.createNewFile(File.java:1008)
        at com.chuckerteam.chucker.internal.support.AndroidCacheFileFactory.create(AndroidCacheFileFactory.kt:21)
        at com.chuckerteam.chucker.internal.support.AndroidCacheFileFactory.create(AndroidCacheFileFactory.kt:15)
        at com.chuckerteam.chucker.api.ChuckerInterceptor.multiCastResponseBody(ChuckerInterceptor.kt:184)
        at com.chuckerteam.chucker.api.ChuckerInterceptor.intercept(ChuckerInterceptor.kt:92)

It happens even after removing the application from device and reinstalling a new one.

[MiSikora]

Well… that's not cool. Does it happen for all requests or only for some of them as well?

@cortinico @vbuberen FYI - don't know if you'd like to reopen this issue or create a new one (technically it is a different thing).

[vbuberen]

Yes, we should open a new issue. I will handle it.

[vbuberen]

@CodeBreak524 I invite you to the new issue to provide more info.