RTL5d: Clarify whether errorReason should be cleared after a clean detach

[paddybyers]

Context

RTL5d specifies that when detach() is called on an attached channel, a DETACH ProtocolMessage is sent and the channel transitions to DETACHED when the confirmation is received. However, the spec does not say what should happen to Channel#errorReason after a successful detach.

Observed behaviour

In ably-js, after a successful detach(), channel.errorReason is set to an ErrorInfo with message "Channel detached" rather than being cleared to null.

Question

Should errorReason be null after a clean, successful detach?

There is a reasonable argument that it should be: the operation completed successfully, so there is no error to report. A client checking channel state after detach and finding a non-null errorReason might incorrectly conclude that something went wrong.

The counterargument might be that errorReason serves as context for why the channel is in its current state. But in the case of a client-initiated detach, the caller already knows why — they asked for it.

Note that the library must, when an operation is attempted on a detached channel, check the channel state and return an appropriate error if the operation is not permitted. It does not need to get that error from the channel's errorReason.

Suggested clarification

Add to RTL5d (or a new sub-point) that on a successful client-initiated detach, errorReason should be set to null.

References

• RTL5d: "Otherwise a DETACH ProtocolMessage is sent to the server, the state transitions to DETACHING and the channel becomes DETACHED when the confirmation DETACHED ProtocolMessage is received"
• Discovered during UTS integration test development