Three `realtime/unit/connection` tests assert two token requests for a basic-auth client that makes one, and a fourth never establishes its transport

[owenpearson]

Summary

Three tests in uts/realtime/unit/connection build a client with an API key and nothing else, and then assert that two token requests were made. A basic-auth client makes no token request for its initial connection, so the correct expectation is one in every case — the renewal, which is what the tests are actually about.

Line references are against d9a04ca; paths are relative to uts/realtime/unit/.

---

The three tests

Each has a mock HTTP handler that counts requests to /keys/, i.e. requestToken calls:

# connection/connection_open_failures_test.md:99-101
onRequest: (req) => {
  IF req.url.path CONTAINS "/keys/":
    token_request_count++

and each builds its client like this:

client = Realtime(options: ClientOptions(
  key: "appId.keyId:keySecret",
  autoConnect: false
))

Test	Site	Client	Assertion
realtime/unit/RTN15h2/token-error-renew-success-0	connection/connection_failures_test.md:91	:154-157	:199 — ASSERT token_request_count == 2 # Initial + renewal
realtime/unit/RTN15c5/token-error-during-resume-0	connection/connection_failures_test.md:920	:994-997	:1023 — the same
realtime/unit/RTN14b/token-error-with-renewal-0	connection/connection_open_failures_test.md:84	:145-148	:169 — the same

features.md:187 (RSA4): "Token Auth is used if useTokenAuth is set to true, or if useTokenAuth is unspecified and any one of authUrl, authCallback, token, or TokenDetails is provided."

None of the three setups supplies any of those, and none supplies a clientId either. So all three clients use basic auth: the key goes in the connection URL and no requestToken is issued for the initial connection. The server then rejects with a token error, the SDK renews, and exactly one token request has been made.

The # Initial + renewal comment shows the intent — the test author had a token-auth client in mind. But the setup is a basic-auth client, and the assertion was presumably never run against a real SDK.

Fix: change the assertion to == 1 in all three places, and drop the # Initial + renewal comment. Alternatively, if the intent really is to cover the token-auth path, give the three clients an authCallback — but == 1 is the smaller change and the renewal is what each of RTN15h2, RTN15c5 and RTN14b is testing.

---

A second, unrelated fault in the same area

realtime/unit/RTN14b/token-renewal-fails-1 (connection/connection_open_failures_test.md:180) never establishes its transport:

# :198-205
mock_ws = MockWebSocket(
  onConnectionAttempt: (conn) =>
    # Always reject with token error
    conn.send_to_client(ProtocolMessage(
      action: ERROR,
      error: ErrorInfo(code: 40142, statusCode: 401, message: "Token expired")
    ))
)

There is no conn.respond_with_success() first, so the connection is never opened and the ERROR message has nothing to travel on. The sibling test at :114-128 in the same file does answer the attempt before sending:

onConnectionAttempt: (conn) => {
  connection_attempt_count++
  conn.respond_with_success()
  IF connection_attempt_count == 1:
    conn.send_to_client_and_close(ProtocolMessage(action: ERROR, ...))

Fix: add conn.respond_with_success() at :200, and use send_to_client_and_close to match the sibling.

(This test also uses the undefined create_realtime_client(...) at :208 — reported separately.)

Found while deriving uts/realtime/unit for ably-python (all 54 specs, 481 tests).