Found while fixing #154.
1. An absent Session Expiry Interval is treated as "never expires"
Spec §3.1.2.11.2: "If the Session Expiry Interval is absent the value 0 is used." With 0, the session ends when the network connection closes.
The broker stores an absent CONNECT property as expiry_interval: None (client_handler/connect.rs create_new_session), and then treats None as never expiring:
ClientHandler::session_preserved() (client_handler/mod.rs) returns true for anything other than Some(0).- The expiry sweep (
storage/mod.rs, ~line 713) only expires sessions whose expiry_interval is Some.
So a client that omits the property keeps its session, subscriptions and queued messages forever, instead of losing them at disconnect. It also changes Will timing, because the Will fires at session end (#154).
Fix: treat an absent CONNECT Session Expiry Interval as 0, in one place, when the session is created or restored. Add conformance tests: connect without the property, subscribe, disconnect, reconnect with Clean Start 0 and expect Session Present=0; and a publish to the subscription while offline is not delivered.
This is a behaviour change for clients that relied on the old default. It needs a CHANGELOG note, and the release should be a minor one.
2. Session Expiry Interval in DISCONNECT is not applied
Spec §3.14.2.2.2: a client may send a Session Expiry Interval in DISCONNECT, which replaces the one from CONNECT for the session that follows. If CONNECT had 0 and DISCONNECT sends a non-zero value, that is a Protocol Error (the server sends DISCONNECT 0x82).
The broker ignores the DISCONNECT property. A client that wants its session to outlive this disconnect (or to end now) can't change it at disconnect time.
Fix: apply the DISCONNECT value to the stored session before the session-end and Will logic runs, and reject 0 → non-zero with 0x82. Add conformance tests for both.
3. The wasm broker does not update Session Expiry on session resume
crates/mqtt5-wasm restore_existing_session keeps the expiry_interval from the original CONNECT instead of the resuming CONNECT's value. A resumed session therefore keeps its old expiry, and that includes the Will timing, which is bounded by session end since #154.
Found while fixing #154.
1. An absent Session Expiry Interval is treated as "never expires"
Spec §3.1.2.11.2: "If the Session Expiry Interval is absent the value 0 is used." With 0, the session ends when the network connection closes.
The broker stores an absent CONNECT property as
expiry_interval: None(client_handler/connect.rscreate_new_session), and then treatsNoneas never expiring:ClientHandler::session_preserved()(client_handler/mod.rs) returns true for anything other thanSome(0).storage/mod.rs, ~line 713) only expires sessions whoseexpiry_intervalisSome.So a client that omits the property keeps its session, subscriptions and queued messages forever, instead of losing them at disconnect. It also changes Will timing, because the Will fires at session end (#154).
Fix: treat an absent CONNECT Session Expiry Interval as 0, in one place, when the session is created or restored. Add conformance tests: connect without the property, subscribe, disconnect, reconnect with Clean Start 0 and expect Session Present=0; and a publish to the subscription while offline is not delivered.
This is a behaviour change for clients that relied on the old default. It needs a CHANGELOG note, and the release should be a minor one.
2. Session Expiry Interval in DISCONNECT is not applied
Spec §3.14.2.2.2: a client may send a Session Expiry Interval in DISCONNECT, which replaces the one from CONNECT for the session that follows. If CONNECT had 0 and DISCONNECT sends a non-zero value, that is a Protocol Error (the server sends DISCONNECT 0x82).
The broker ignores the DISCONNECT property. A client that wants its session to outlive this disconnect (or to end now) can't change it at disconnect time.
Fix: apply the DISCONNECT value to the stored session before the session-end and Will logic runs, and reject 0 → non-zero with 0x82. Add conformance tests for both.
3. The wasm broker does not update Session Expiry on session resume
crates/mqtt5-wasmrestore_existing_sessionkeeps theexpiry_intervalfrom the original CONNECT instead of the resuming CONNECT's value. A resumed session therefore keeps its old expiry, and that includes the Will timing, which is bounded by session end since #154.