RTN17f:
Errors that necessitate use of an alternative host include any of the failure conditions specified in RSC15l, and additionally also (…)
But — and perhaps I've just not read things properly — I can't see anywhere where we take into account the error when deciding whether to use a fallback host:
https://github.com/ably/ably-ruby/blob/e9a8a60cb55f8c30a2b1d98f2f745ae08fdd1c81/lib/ably/realtime/connection.rb#L676-L702
Amongst other things, this means that a realtime connection tries using a fallback host when it fails to establish a connection due to a token error.
I am a bit hesitant about trying to change this code in a rush because I don't fully understand its logic for deciding when to use a fallback host; there is some complicated-looking logic that considers the history of state changes that the connection has been through, which doesn't (at least, obviously) match up to any behaviour described in the spec.
(I've done a partial fix for this in #443, to explicitly prevent token errors from triggering usage of fallback hosts, but it needs fixing properly to instead only use a fallback host when faced with one of the errors described in RTN17f. To do that would require a deeper understanding of how these errors manifest inside our library.)
Note that the REST code does seem to care about the nature of the error:
https://github.com/ably/ably-ruby/blob/e9a8a60cb55f8c30a2b1d98f2f745ae08fdd1c81/lib/ably/rest/client.rb#L616-L643
┆Issue is synchronized with this Jira Task by Unito
RTN17f:
But — and perhaps I've just not read things properly — I can't see anywhere where we take into account the error when deciding whether to use a fallback host:
https://github.com/ably/ably-ruby/blob/e9a8a60cb55f8c30a2b1d98f2f745ae08fdd1c81/lib/ably/realtime/connection.rb#L676-L702
Amongst other things, this means that a realtime connection tries using a fallback host when it fails to establish a connection due to a token error.
I am a bit hesitant about trying to change this code in a rush because I don't fully understand its logic for deciding when to use a fallback host; there is some complicated-looking logic that considers the history of state changes that the connection has been through, which doesn't (at least, obviously) match up to any behaviour described in the spec.
(I've done a partial fix for this in #443, to explicitly prevent token errors from triggering usage of fallback hosts, but it needs fixing properly to instead only use a fallback host when faced with one of the errors described in RTN17f. To do that would require a deeper understanding of how these errors manifest inside our library.)
Note that the REST code does seem to care about the nature of the error:
https://github.com/ably/ably-ruby/blob/e9a8a60cb55f8c30a2b1d98f2f745ae08fdd1c81/lib/ably/rest/client.rb#L616-L643
┆Issue is synchronized with this Jira Task by Unito