validatorResponseInterceptor always response FuelError
See original GitHub issueFuel: v1.12.0
I add validatorResponseInterceptor(200..499)
to FuelManager
Should it allow 200 to 499 as valid status code?
I checked FuelManager
that it add validatorResponseInterceptor
as new interceptor, but it already has validatorResponseInterceptor(200..299)
. So it might do the 200..299
before my interceptor and response error.
Here is my code
with(FuelManager.instance) {
basePath = BuildConfig.BASE_URL
addResponseInterceptor(validatorResponseInterceptor(200..499))
}
"xxx".httpPost()
.responseObject(...) { _, _, result ->
// status code is 422
result.fold({ items ->
// Should it response here?
}, { error ->
// Always get error
})
}
Issue Analytics
- State:
- Created 6 years ago
- Comments:11 (5 by maintainers)
Top Results From Across the Web
validatorResponseInterceptor always response FuelError #301
Fuel: v1.12.0 I add validatorResponseInterceptor(200..499) to FuelManager Should it allow 200 to 499 as valid status code?
Read more >Fuel get the body response on error - android - Stack Overflow
As it is mentioned in this issue. You can receive the body with response.data , which returns ByteArray . Therefore the code could...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
You are right, true … I think we should do that. Sound like a good item for another PR.
I think we could improve in this block.
https://github.com/kittinunf/Fuel/blob/0001c44efe9bf1389ba742292a45b62837723801/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/Deserializable.kt#L69-L73
But, going down this route, we require passing in an Error type and we probably need to upgrade our class to
FuelError<T>
to accommodate this.Call-site could be ugly.
Before
After
Then, it looks 😢 😭
Another idea is to make the deserializable of error object become a bit more like “on-demand”
So, we add a ability to deserialize into the
FuelError
class.Yeah. I think I could find some time this weekend to tackle this