yeah, seems simpler!

edit: what do you think about adding a case so ErrorKind::BuildRequestClient can get mapped to timeout and unsupported statuses? it would match the old behaviour in cases aside from data URIs

basically, just

+     ErrorKind::BuildRequestClient(e) => Status::from(e),

@katrinafyi Hmm that might make sense.

it would match the old behaviour

Do you have an example of that, or could you point me to a specific line? I don't remember having changed that 😅
We would ideally add a test which covers that case too, as documentation.

@thomas-zahner I tried a few things and don't have a concrete example, sadly. But it's the same premise as I wrote in the description of #1982, and the line change would look like the change to lychee-lib/src/types/status.rs here: rina-forks@5bcd700

The idea is that if you have a reqwest::Error, there are different ways to end up at a lychee Status. At the moment, some reqwest::Error will lead to a different Status depending on what path you take. I think this can be subtle and surprising, especially given implicit conversions within ? operator.

I think that either the two paths should be made to be logically the same (by adding this extra case), or the reqwest::Error → Status edge should be deleted and it all goes through ErrorKind first.

flowchart LR

reqwest::Error -->|Into| ErrorKind
reqwest::Error -->|Into| Status
ErrorKind -->|Into| Status

@katrinafyi Thank you very much for the explanation. The diagram really helps!

What do you think if we just remove (or rather inline) the conversion from reqwest:Error to Status, this feels pretty clean. Also I realised that this conversion wasn't even used except for one place.

See 136913b

@thomas-zahner looks good!