fix(browser): surface mqtt-js errors during CONNECT as CONNECTION_FAILURE

[kamal]

Summary

When the browser MQTT5 client encounters an error from mqtt-js during the Connecting lifecycle state, the error is silently swallowed:

1. on_browser_client_error stores the error in lastError and emits it on the INFO event
2. No CONNECTION_FAILURE event is ever emitted
3. The underlying WebSocket can remain open indefinitely with no MQTT frames sent
4. The connection hangs silently — consumers and the reconnection scheduler never learn about the failure

Reproduction

One concrete way to trigger this: pass a Uint8Array as the password to newWebsocketMqttBuilderWithCustomAuth. The CRT types accept binary data, but the underlying mqtt-js v4 writeToStream rejects anything that isn't string | Buffer with Error: Invalid password. In the browser there is no native Buffer, so Uint8Array instanceof Buffer is always false.

The WebSocket handshake succeeds (HTTP 101), but mqtt-js fails to serialize the CONNECT packet and emits an error event. The CRT wrapper catches this in on_browser_client_error, stores it in lastError, and emits on INFO — but since no MQTT frames are sent, the server never closes the WebSocket, on_browser_close is never called, and CONNECTION_FAILURE is never emitted.

Fix

When an error occurs while lifecycleEventState == Connecting, force-close the mqtt-js client so that the normal on_browser_close → CONNECTION_FAILURE path fires. This lets consumers and the reconnection scheduler react to the failure.

Test plan

• Verify existing browser MQTT5 tests still pass
• Confirm that passing an invalid password type triggers CONNECTION_FAILURE instead of hanging
• Confirm the reconnection scheduler picks up the failure and retries

🤖 Generated with Claude Code

[bretambrose]

This seems like a reasonable workaround (tbh I think mqtt-js should handle this case on their own as well). However, we are very near moving off of mqtt-js entirely (probably a couple of weeks) so I'm unsure if it's worth pushing this through. If you feel strongly about this I can push it through in the short-term though.

[kamal]

@bretambrose I don't feel strongly about it. Interested to know what you'll be moving to?

[bretambrose]

@bretambrose I don't feel strongly about it. Interested to know what you'll be moving to?

An internal implementation that follows the same architecture and approach as the native mqtt5 client. PRs are up; what remains is an integration PR that switches everything over and some stress testing.