question: intended behavior with failed auth and async for auto-reconnect

[francisferrell]

question: intended behavior with failed auth and async for auto-reconnect

[aaugustin]

In short, you're expecting websockets to tell retriable errors apart from non-retriable errors here

If memory serves, when I implemented the automatic reconnection feature, I decided to walk away from trying to make that distinction automatically because I couldn't draw confidently a line between retriable and non-retriable that would work for all users.

If you had to draw that line, what criteria would you use? Apart from the specific example here (HTTP 403 isn't retriable)?

[francisferrell]

In my particular case, it's a 401 used when authentication credentials are missing or invalid. I would deem this to be a non-retriable situation. That's pretty clear cut to me personally, the user's password or API token is unlikely to suddenly become valid. My use case doesn't include 403 so I hesitate to comment.

As an application developer using this library, my desire is that such an auto reconnect feature makes my app substantially more resilient again things I'm not in control of. That primarily means connection timed out, connection refused, and many maybe even all 5xx class response codes. Meanwhile, 4xx is largely within my control and if I get one then it means I need to change something about how I'm connecting before the next attempt.

As a library developer, if I were in your position, I'm not sure how I'd draw the line for all possible http response codes. No answer is likely to work for all users. That being said, I am drawn to the fact that different 3xx codes have explicit semantics around retrying, e.g. temporary vs permanent redirect. 4xx feels like a range of codes that are not retriable. I'm not sure if the spec actually backs up my feeling; but then the spec will only take one so far, as real browser and server implementations deviate from the spec.

[francisferrell]

Ultimately I decided to implement auto-reconnect myself with a service layer presenting a run_forever() entrypoint with exponential backoff in the reconnect logic.

I still think that, in theory, async for websockets.connect() could benefit from understanding what types of http responses to the Upgrade request are retryable and which are not. I also understand that without concrete user interest in that feature it's reasonable to close a ticket like this. Thanks for your work providing this excellent library!