Problem
RSA4c1 currently states:
An ErrorInfo with code 80019, statusCode 401, and cause set to the underlying cause should be emitted with the state change if there is one (per RSA4c2/3) and set as the connection errorReason
RSA4c3 states:
If the connection is CONNECTED, then the connection should remain CONNECTED
The phrase "if there is one" in RSA4c1 acknowledges that RSA4c3 produces no state change. However, RSA4c1 still requires setting errorReason, which creates an inconsistency: the connection is ostensibly healthy (the existing token is still valid and the connection remains CONNECTED), yet errorReason is set to a non-null error with no corresponding event for the client to react to.
In the RSA4c3 case, the token renewal attempt failed but the current token is still valid — there is no problem with the connection yet. Setting errorReason on a healthy connection with no accompanying state change or event is misleading. When the token eventually expires, there will be a further renewal attempt, and that failure will be surfaced via the normal connection state machine (RTN15h etc.).
Proposed change
Delete RSA4c1 as a standalone clause and absorb its error definition into RSA4c2:
Before:
(RSA4c1) An ErrorInfo with code 80019, statusCode 401, and cause set to the underlying cause
should be emitted with the state change if there is one (per RSA4c2/3) and set as the
connection errorReason
(RSA4c2) If the connection is CONNECTING, then the connection attempt should be treated as
unsuccessful, and as such the connection should transition to the DISCONNECTED or
SUSPENDED state as defined in RTN14 and RTN15
(RSA4c3) If the connection is CONNECTED, then the connection should remain CONNECTED
After:
(RSA4c2) If the connection is CONNECTING, then the connection attempt should be treated as
unsuccessful, and as such the connection should transition to the DISCONNECTED or
SUSPENDED state as defined in RTN14 and RTN15. An ErrorInfo with code 80019,
statusCode 401, and cause set to the underlying cause should be emitted with the
state change and set as the connection errorReason.
(RSA4c3) If the connection is CONNECTED, then the connection should remain CONNECTED
RSA4c1 would be deleted. The error definition moves into RSA4c2 where it actually applies. RSA4c3 becomes purely "stay CONNECTED, do nothing" — the auth failure is silently swallowed, and will naturally surface when the token expires and the next renewal also fails.
RTN25 references RSA4c1 and would need updating to reference RSA4c2 instead.
Evidence
ably-js already behaves this way (does not set errorReason on auth failure while CONNECTED). This was recorded as a deviation from the spec, but it turns out ably-js's behaviour is correct and the spec text is what needs fixing.
Problem
RSA4c1 currently states:
RSA4c3 states:
The phrase "if there is one" in RSA4c1 acknowledges that RSA4c3 produces no state change. However, RSA4c1 still requires setting
errorReason, which creates an inconsistency: the connection is ostensibly healthy (the existing token is still valid and the connection remains CONNECTED), yeterrorReasonis set to a non-null error with no corresponding event for the client to react to.In the RSA4c3 case, the token renewal attempt failed but the current token is still valid — there is no problem with the connection yet. Setting
errorReasonon a healthy connection with no accompanying state change or event is misleading. When the token eventually expires, there will be a further renewal attempt, and that failure will be surfaced via the normal connection state machine (RTN15h etc.).Proposed change
Delete RSA4c1 as a standalone clause and absorb its error definition into RSA4c2:
Before:
After:
RSA4c1 would be deleted. The error definition moves into RSA4c2 where it actually applies. RSA4c3 becomes purely "stay CONNECTED, do nothing" — the auth failure is silently swallowed, and will naturally surface when the token expires and the next renewal also fails.
RTN25 references RSA4c1 and would need updating to reference RSA4c2 instead.
Evidence
ably-js already behaves this way (does not set errorReason on auth failure while CONNECTED). This was recorded as a deviation from the spec, but it turns out ably-js's behaviour is correct and the spec text is what needs fixing.