Do not fail requests when side channel file cannot be used#396
Conversation
vbuberen
left a comment
There was a problem hiding this comment.
LGTM. Thanks for another great contribution.
As you said, responses would have to be loaded in memory anyway (e.g. you have to show an image, parse the body of a JSON to split it in strings, etc). I feel that the file approach we have right now is way more robust than before, where we just loaded everything in memory with subsequent OOM errors. I'll suggest that we stick to it and try to refine it following issue reports (as we're doing) 👍 |
|
Agree with @cortinico here that current approach looks pretty robust for now. |
📄 Context
There is an open issue - #394.
📝 Changes
TeeSourceguards against failures to use files. WhenFileNotFoundExceptionoccurs when opening a stream it is reported back to the caller and no payload side streaming happens. Also, any IO failures during interception are now logged.🚫 Breaking
No.
🛠️ How to test
Not really sure how to reproduce this manually without a convoluted setup. Maybe @CodeBreak524 can confirm that their issue is fixed with a dependency from my branch on JitPack (
com.github.MiSikora.chucker:library:side-channel-file-failure-SNAPSHOT). I don't really feel that it is necessary as the description in #394 is quite clear and it is now covered with tests.⏱️ Next steps
Closes #394.
To be honest I wonder now about the necessity to write to a file instead of to the memory. Responses need to be loaded to a memory at some point anyway.
chucker/library/src/main/java/com/chuckerteam/chucker/api/ChuckerInterceptor.kt
Lines 251 to 259 in ba2c21b
I pushed for a file-based solution before because of parallel downloads but I didn't consider that the content of files needs to be read to the memory before it is saved to the DB. However, there is still an advantage of files that could be leveraged. Files could be saved to some non-volatile directory instead of cache and DB could just store handles to these files (processing still would be required as we need to decompress network streams). I see the pros and cons of both solutions and I'm open to suggestions.