Split read/write/connect timeout error classes

[maxim]

What do you think about splitting Timeout error classes into ReadTimeout/WriteTimeout/ConnectTimeout?

If I understand correctly, when handling destructive (non-idempotent) actions in APIs

• a connect timeout means the action was definitely not performed
• a write or read timeout means that the action may have been performed

So it seems different recovery procedures should take place to resolve the status of the action, depending on the type of the timeout.

Right now, we'd have to parse the error message to tell them apart.

Do you think it makes sense to have them all be their own classes, inheriting from Timeout? The inheritance would maintain backwards compatibility.

[geemus]

Hey, thanks for the detailed report. At least initially I would say that split makes sense to me. As you suggest, if they inherit it should nicely allow for backwards compatibility.

I also would agree that my expectation is that connect timeouts can safely be retried, whereas read/write timeouts are more ambiguous (you might or might not be able to make further assumptions depending on how much you know about the server in question).

So overall I am supportive of exploring this. It seems pretty straightforward so far, though perhaps we'll find challenges as we get into it. I'm certainly happy to support work on this, is this something you would be able and willing to work on? Thanks!

[maxim]

@geemus Great! I gave it a shot. Left a few notes in the PR, let me know if anything doesn't sit right with you.

[maxim]

Pushed a couple of fixups, hope I didn't mess up your review. 🤞🏻

[geemus]

@maxim no worries, I hadn't quite found time for review yet anyway. Will take a look now.

[maxim]

I will proceed after we make this decision, but absolutely no rush. Just clarifying why I'm not submitting revisions yet.