You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
[mqtt5 0.47.0] - 2026-10-05
Breaking
Minimum supported Rust version is now 1.89 (was 1.88), for std::fs::File::try_lock.
A broker refuses to start on a storage directory another broker is using (#179). Since 0.42.0 all session writes go to one append-only log, <storage_dir>/sessions/sessions.log, and nothing stopped two brokers, in one process or in two, from opening the same directory. Both then wrote and compacted the same log, so one broker's compaction could drop sessions the other had written: with two brokers on one directory, a session written through the first broker was gone after a restart. The file backend now takes an exclusive lock on <storage_dir>/.lock when it opens the directory and holds it until the backend is dropped, after the last connection handler has finished with storage; the OS releases it if the process exits or crashes. A second broker on the same directory fails in MqttBroker::with_config with Storage directory <dir> is already in use by another broker. Two mqttv5 broker processes started from the same working directory with the default ./mqtt_storage, or sharing --storage-dir, now hit this error instead of sharing the directory. In-memory storage is not affected. On a filesystem where file locking is not supported (ErrorKind::Unsupported), the broker logs a warning and starts without the lock, as before.
run_quic_connection_handler and run_quic_cluster_connection_handler take a QuicHandlerContext in place of their seven separate broker arguments.
Changed
Graceful shutdown now waits for connection handlers.MqttBroker::run() used to return while connection handlers were still writing their final session state, so those writes could still be in progress after run() returned. run() now returns once every connection handler has finished, within the existing 5 second shutdown wait; if that wait runs out it logs a warning and returns. The release point and the wait are modelled in specs/tla/storage-lock/.
Graceful shutdown also waits for the $SYS topics task and for the bridge tasks it aborts. With bridges configured, the bridge client's connection monitor still exits a few milliseconds after run() returns, so the storage directory is released that much later.
Integration tests that started brokers on the default ./mqtt_storage in parallel now use in-memory storage.
Fixed
MqttClient::disconnect() now stops the connection monitor at once. The monitor only checked for a stop once a second, so after disconnect() it kept the client, its callbacks and anything they hold alive for up to a second. A broker with a bridge held its storage directory that long after shutdown.
[mqttv5-cli 0.29.6] - 2026-10-05
Changed
Requires mqtt5 0.47. mqttv5 broker now refuses to start when another broker holds its storage directory.
[mqtt5-wasm 2.1.5] - 2026-10-05
Changed
Requires mqtt5 0.47. No change to the wasm API; the wasm broker uses in-memory storage and takes no directory lock.