🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 Add Last Will support to the public MQTTClient API (#45)


Problem

zmqtt already implements MQTT Last Will at the packet/codec level, but it
cannot be configured through the public high-level client API.

Currently:

• Will and WillProperties are only available through private
 zmqtt._internal modules;
• MQTTClient and create_client() do not accept a will= argument;
• MQTTClient._connect() builds every CONNECT packet without a Will.

As a result, users and frameworks built on the public zmqtt.MQTTClient API,
including FastStream, cannot configure an MQTT Last Will without depending on
private implementation details.

Proposed API

from zmqtt import MQTTClient, QoS, Will, WillProperties

will = Will(
    topic="devices/device-42/status",
    payload=b"offline",
    qos=QoS.AT_LEAST_ONCE,
    retain=True,
    properties=WillProperties(
        will_delay_interval=10,
        content_type="text/plain",
    ),
)

client = MQTTClient(
    "broker.example.com",
    version="5.0",
    will=will,
)

For MQTT 3.1.1, the same Will type should be usable without
WillProperties.

Scope
• Export Will and WillProperties from the top-level zmqtt package.
• Add will: Will | None = None to MQTTClient.
• Add the same argument to create_client() and all of its typed overloads.
• Store the configured Will and pass it to every Connect packet created by
 the client.
• Preserve the same Will configuration when the client reconnects after an
 established connection is lost.
• Reject MQTT 5.0 Will properties on MQTT 3.1.1 with a clear error consistent
 with other version-specific options.
• Keep the current behavior unchanged when will=None.

Tests

The tests should exercise the public client path rather than only the existing
packet codec:

• MQTT 3.1.1: construct MQTTClient(..., will=...), decode the emitted
 CONNECT, and verify the Will topic, payload, QoS, and retain flag.
• MQTT 5.0: verify the same fields together with WillProperties.
• Simulate will receiving of second client when the first reconnected unexpectedly

Tests should test public behaviour with real broker instead internals testing and avoid monkey patching.


#enhancement #good_first_issue #faststream #zmqtt
sent via relator

🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 Supress Artemis flaky test (#57)


Race condition in Artemis produces flaks on message ordering tests (https://issues.apache.org/jira/browse/ARTEMIS-6191). We have to supress it while ordering is broken in Artemis.
Flaky run: https://github.com/faststream-community/zMQTT/actions/runs/32063447688/job/95489785526
Left artemis issue link pytest.skip.


#good_first_issue #faststream #zmqtt
sent via relator

🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 MQTT 5 publish() silently succeeds when PUBACK or PUBREC rejects the message (#65)


Summary

MQTTClient.publish() returns normally when an MQTT 5 broker rejects a QoS 1 or QoS 2 PUBLISH with a negative acknowledgement reason code.

For example, Mosquitto returns 0x87 (Not authorized) for an ACL-denied publication:

Received PubAck(packet_id=1, reason_code=135, properties=None)

The message was not accepted by the broker, but await client.publish(...) completes without an exception.

Current behavior

For QoS 1, _handle_puback() resolves the publish future successfully without checking PubAck.reason_code.

For QoS 2, _handle_pubrec() also ignores the reason code and sends PUBREL even when PUBREC contains 0x87. MQTT 5 only permits PUBREL after a PUBREC reason code below 0x80.

The public MQTTClient.publish() method discards the acknowledgement returned by MQTTProtocol.publish().

Expected behavior
• PUBACK/PUBREC reason codes below 0x80, including 0x00 and 0x10 (No matching subscribers), complete successfully.
• A PUBACK or PUBREC reason code of 0x80 or greater raises a public MQTTPublishError.
• The exception exposes at least reason_code; exposing the optional Reason String would also be useful.
• A negative PUBREC completes and removes the QoS 2 flight, releases its packet identifier, and does not send PUBREL.
• The MQTT connection remains usable after the rejected operation.
• MQTT 3.1.1 behavior remains unchanged because PUBACK and PUBREC do not carry reason codes in that protocol version.

MQTTPublishError would be consistent with the existing MQTTSubscribeError.

Protocol references
• MQTT 5.0 section 2.4: reason codes 0x80 and greater indicate failure.
• MQTT 5.0 section 3.4.2.1: PUBACK 0x87 means the PUBLISH is not authorized.
• MQTT 5.0 section 3.5.2.1: PUBREC has the same publish-rejection reason codes.
• MQTT 5.0 section 4.3.3: PUBREL is sent only after a PUBREC reason code below 0x80.
• MQTT 5.0 section 4.4: a negative PUBACK/PUBREC acknowledges the packet for retry purposes, but does not make the publication successful.
• MQTT 3.1.1 section 3.3.5: when a PUBLISH is not authorized, the server must either send a positive acknowledgement or close the connection because the protocol has no negative publish acknowledgement.

Reproduction result

Reproduced with Mosquitto 2.1.2 and a read-only ACL:

MQTT 5 QoS 1:
Received PubAck(packet_id=1, reason_code=135, properties=None)
publish() returned normally

MQTT 5 QoS 2:
Received PubRec(packet_id=1, reason_code=135, properties=None)
QoS 2 PUBREC received, sent PUBREL
publish() returned normally

Mosquitto logs Denied PUBLISH for both messages.

Suggested tests
• QoS 1 negative PUBACK raises and releases the packet identifier.
• QoS 1 0x10 completes successfully.
• QoS 2 negative PUBREC raises, releases the packet identifier, and sends no PUBREL.
• Optional Reason String is preserved in the exception.
• MQTT 3.1.1 ACK behavior is unchanged.

#good_first_issue #faststream #zmqtt
sent via relator

🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 MQTT 5: expose structured metadata from broker DISCONNECT packets (#89)


Problem

In zmqtt 0.2.1, a broker DISCONNECT becomes a generic MQTTDisconnectedError containing the reason code only in its message text. Decoded Reason String, User Properties, and Server Reference are discarded. Applications cannot reliably inspect why the broker closed the connection.

The relevant paths are _dispatch(), DisconnectProperties, and MQTTDisconnectedError.

Expected behavior

Implement support for MQTT 5 §3.14, DISCONNECT:

• Expose the broker's reason_code, Reason String, User Properties, and Server Reference as structured public data.
• Make the event observable even when automatic reconnect subsequently succeeds.
• Preserve these details when a broker disconnect is propagated to affected callers.
• Distinguish a broker DISCONNECT from a transport failure where no MQTT reason code was received.
• Keep duplicate User Property keys and avoid requiring applications to parse exception text.

Related: #85 exposes the corresponding CONNACK metadata. Following Server Reference is a separate feature.


#good_first_issue #opensource_september #faststream #zmqtt
sent via relator

🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 Mark flaky Artemis test xfail (#104)


Artemis test flaks here: https://github.com/faststream-community/zMQTT/actions/runs/35749462095/job/106819499609

Mark it xfail(strict=False)


#good_first_issue #opensource_september #faststream #zmqtt
sent via relator