MQTT Will Delay and Session Expiry: Avoid False Offline Events During Recovery

A delayed Will is eligible when its delay expires or its MQTT session ends, whichever comes first. A long Will Delay cannot provide a reconnect grace period if Session Expiry ends the session immediately. To suppress a Will during a brief interruption, the client must reconnect to the same surviving session before the relevant boundary.

This guide pins the OASIS MQTT 5.0 Standard, 7 March 2019. The primary scenario is an abrupt loss of a connection that has a configured Will. An original nominal-timing model was executed; no broker timing, device outage or network recovery measurement is claimed.

Place both timers on the same timeline

Record the effective Will Delay and Session Expiry intervals, plus the event that closes the network connection. Sections 3.1.3.2.2 and 3.1.2.11.2 define their roles. With ordinary progressing clocks and no reconnect, the illustrative eligibility interval is the smaller of the two values.

Will Delay defaults to zero when absent. Session Expiry also defaults to zero when absent, ending the session when the connection closes. Therefore configuring only a thirty-second Will Delay while leaving Session Expiry at zero does not establish thirty seconds of suppression. The session-end branch is already immediate.

Distinguish reconnecting from continuing the session

A successful new TCP or TLS connection is not enough. Record the ClientID, Clean Start and returned Session Present state. The Will-suppression condition concerns a new network connection to the same MQTT session before the Will Delay has passed. A different identifier or a new clean session does not demonstrate that condition.

A Clean Start replacement can end the previous session while its Will Delay is still pending. That makes the old Will eligible through session termination. This is especially relevant when a reconnect helper always requests a clean start, even though the product’s presence design expects short interruptions to be hidden.

Keep provisioning collisions separate from intentional recovery. Another accepted client using the same identifier can replace a connection, but it is not automatically the device whose state the consumer intends to monitor. Presence logic needs an identity and session-ownership contract as well as timers.

Use a timing truth table

The following values are hypothetical seconds from abrupt connection closure. They are the eight cases checked by the local model, not measured server behavior:

Will Delay / Session Expiry	Other event	Nominal outcome
30 / 60	No reconnect	Will eligible at 30
30 / 10	No reconnect	Session ends; Will eligible at 10
30 / 0	No reconnect	Session-end branch is immediate
30 / 60	Same session resumes at 5	Pending Will suppressed
30 / 60	Clean Start replacement at 5	Old session ends; old Will eligible at 5
5 / 30	Same session resumes at 7	Will was already eligible at 5
0 / 60	No reconnect	Will-delay branch is immediate
30 / 60	Normal client DISCONNECT 0x00	Will discarded without publication

Section 3.14.4 supplies the normal-disconnect rule in the last row. Do not generalize that row to every DISCONNECT reason or abrupt close. A test that gracefully stops a client can avoid its Will entirely and therefore fail to exercise the recovery behavior being investigated.

Test strictly before, at and after the boundary

Begin with large, observable intervals and an isolated presence topic. Force an abrupt connection loss through an approved lab mechanism, then reconnect clearly before the earlier boundary with the same session. Confirm the server actually resumed it and that no pending Will was published.

Repeat with reconnect clearly after eligibility, with Session Expiry shorter than Will Delay, and with Clean Start replacement. Then test close to the boundary. Do not count an exactly-at-boundary reconnect as guaranteed suppression: capture the server’s accepted-connection and timer-processing order rather than relying only on a client’s wall-clock estimate.

The model deliberately excluded equality ordering, server restart and stalled clocks. The standard discusses clock and stored-session limitations; it does not turn a configured interval into a measured end-to-end delivery deadline. Report actual observed publish and receive times separately when testing the selected broker.

Do not interpret the Will as a physical-health certificate

A Will reflects an MQTT connection/session event under the configured policy. It does not independently prove that a machine lost power, that an actuator stopped, or that all other network interfaces failed. Give the presence payload a meaning that matches the evidence, such as loss of this supervised MQTT connection.

For a hypothetical gateway, a consumer might receive an old connection’s offline Will near a new online announcement. Include a connection or application generation in the presence contract and define how the consumer handles older generations. This is an application design recommendation, not an automatic ordering or freshness guarantee supplied by the Will mechanism.

Likewise, distinguish publication time from observation time. Consumer backlog or delivery interruption can make a correctly generated Will arrive late. Adding a longer Will Delay cannot repair every downstream ordering or freshness problem.

Qualification record

• Broker and client-library versions, plus effective CONNECT/CONNACK session settings
• Will topic, nonsecret test payload, QoS and retain policy
• Connection-close cause and whether normal DISCONNECT was sent
• Reconnect acceptance, Clean Start and Session Present evidence
• Will eligibility model, actual publication time and consumer observation time
• Untested restart, clock and failure conditions

Accept the design when short interruptions continue the intended session and suppress the pending Will, while session termination and longer outages produce the explicitly expected presence transition. The result should explain why an offline event occurred, not merely show that one delay setting is larger than another.