Two different timeout error types when using .into_json() about ureq HOT 6 CLOSED

Thanks for the report! It looks like this is probably a difference between what happens when there's a timeout receiving headers vs a timeout reading the body. into_json maps all errors from serde_json::from_reader into InvalidData. I think the right solution here is to only map errors that are not already an IoError, and pass through IoErrors unchanged.

from ureq.

I will try to make a pull request

from ureq.

I think the right solution here is to only map errors that are not already an IoError, and pass through IoErrors unchanged.

As far as I can tell, there's no way to know the underlying error type in a serde_json::Error. Looking at its docs it doesn't expose any functions that would allow us to extract a std::io::Error.

I don't even know if the "timed out reading response" error message is actually a std::io::Error or serde_json's own error - its API doesn't expose this information.

The best workaround I can think of is to format the serde_json::Error into a string and return IoError::TimedOut if the error message equals "timed out reading response".

from ureq.

@kangalioo Thanks for looking into this. I think it should be possible to get out the original io::Error

First we have is_io, which isn't strictly needed.

Then we have source by virtue of serde_json::Error implementing std::error::Error.

And finally we have downcast_ref to get the ref to the io::Error.

from ureq.

I've looked into this the past 1-2 hours and I can't find a way to get the actual owned io::Error. std::error::Error::source exists, but it only returns an immutable reference. We'd need an owned value (or a mutable value to use with std::mem::replace and get the owned value).

from ureq.

@kangalioo I see the problem. .source() doesn't let us get the actual error. I've implemented a PR that clones the original error as closely as possible. See #123

from ureq.