fix: [sc-96140] Set explicit MQTT ConnectTimeout instead of relying on paho default#76
Merged
mlataza merged 2 commits intoJun 5, 2026
Conversation
…n paho default Own the MQTT connect timeout in our code rather than depending on paho.mqtt.golang's implicit 30s default, so reconnect timing stays predictable across paho upgrades. The default is set to the reconnect backoff base interval so a connect attempt can never outlive the next backoff slot, and it can be overridden per-device via the existing device config (mqtt_connect_timeout_seconds). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mlataza
deleted the
bug/sc-96140/set-explicit-mqtt-connecttimeout-instead-of
branch
June 5, 2026 14:01
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The MQTT client options assembled in
runCyclesetAutoReconnect=falseand anOnConnectionLostcallback, but never calledSetConnectTimeout— so initial-connect/subscribe operations silently relied on paho.mqtt.golang's implicit 30s default. This coupled our reconnect behaviour to an undeclared library default that could drift across pinned paho versions without any signal in our code.This PR makes the connect timeout fully owned by our code so reconnect behaviour stays predictable across paho upgrades.
Changes
internal/utils/time.go— AddedInitialReconnectInterval(1s), now the seed for the reconnect backoff, plusDefaultMqttConnectTimeoutas a documented constant alongside the backoff parameters. The default is<=the shortest possible backoff slot (1.5 × InitialReconnectIntervalafter worst-case jitter), so a connect attempt can never outlive the next backoff slot.internal/agent/device.go— Added optional per-device overridemqtt_connect_timeout_seconds(mirroring the existingmqtt_qostunable) and aDevice.MqttConnectTimeout()helper.internal/mqtt/common.go—NewClientOptionsnow callsopts.SetConnectTimeout(...)centrally for all broker paths.common_test.go; record the chosen timeout/rationale and prove it fits within the backoff intime_test.go.Acceptance criteria
Notes
The default is 1s, a behavioural reduction from paho's old 30s, chosen to strictly satisfy the "never outlives the next backoff slot" criterion. Tenants with occasionally slow TLS handshakes are covered by the new per-device
mqtt_connect_timeout_secondsoverride rather than a looser default.🤖 Generated with Claude Code