Fenrir med

BROKER.md

@@ -201,3 +201,7 @@ The CONNECT-handler unit test (`tests/test_broker_connect`) is part of `make che
 ## Limitations
 
 The wolfMQTT broker targets embedded and edge use cases. It is intentionally smaller in scope than full-featured server brokers such as Mosquitto or EMQX: there is no clustering, no bridging, no plugin/ACL framework, and no dynamic configuration reload. For large-scale or feature-rich deployments use a dedicated server broker; for a small, auditable, optionally-TLS broker that runs without threads or a heap, wolfMQTT is a good fit.
+
+Fan-out of a PUBLISH to its subscribers is not atomic. If the broker runs out of memory part-way through queueing copies of a QoS 1 or QoS 2 message, subscribers already served keep their copy and the publisher is not told the message was accepted: an MQTT v5 publisher receives a PUBACK or PUBREC with Reason Code 0x80, and an MQTT v3.1.1 publisher is disconnected. For a v3.1.1 QoS 2 publisher with a persistent session, the retransmitted PUBLISH is then treated as a duplicate, so subscribers that missed the original fan-out do not receive it.
+
+A single MQTT v5 packet may carry at most `MQTT_MAX_PROPS` (default 30) properties. The MQTT specification sets no such limit, but the broker rejects a packet with more properties as it would a malformed one. For a DISCONNECT this means the connection is treated as closed abnormally, so the client's Will Message is published even when the Reason Code is 0x00 (Normal disconnection). A DISCONNECT within the limit whose properties cannot be allocated because the broker is out of memory is still handled according to its Reason Code.