RSC1b says about REST client constructor:

If invalid arguments are provided such as no API key, no token and no means to create a token, then this will result in an error with error code 40106 and an informative message.

And RTN14a says about connection failure:

If an API key is invalid, then the connection will transition to the FAILED state and the Connection#errorReason will be set on the Connection object as well as the emitted ConnectionStateChange

And RTN14g says about non-token ERROR responses when connecting:

If an ERROR ProtocolMessage with an empty channel attribute is received for any reason other than RTN14b, then the connection will transition to the FAILED state and the server will terminate the connection. Additionally the Connection#errorReason must be set with the error from the ERROR ProtocolMessage

RSC1b is usually implemented (Java, JavaScript, Go) by throwing/returning an error in the REST constructor, and, by extension, the Realtime constructor, since Realtime extends or embeds REST.

@gernest points out that this implies RTN14a can't happen or is redundant:

• If the key is invalid because it's malformed it a way that can be checked by the client, then RSC1b may already handle that and, the way it's commonly implemented, prevents the Realtime instance from existing in the first place.
• If the key is invalid because the server rejects it, then RTN14g already handles that.

Of course, RSC1b is ambiguous enough that checking "invalid arguments" may not involve checking a malformed key, and "result in an error" may not actually prevent the Realtime instance from being created.

So I see two options to reconcile this:

• Keep the ambiguity in RSC1b but make it explicit that RTN14a applies to malformed keys and only if the way RSC1b is implemented doesn't prevent this from being possible already. This has the advantage that existing libraries keep being spec-compliant.
• Just remove RTN14a, make it explicit that RSC1b should "soft" validate the key, and that this error should be an exception-like error that prevents the creation of the instance. (We should then also change the IDL signature of the REST/Realtime constructors too.)

┆Issue is synchronized with this Jira Task by Unito