Describe the bug
When Z_FEATURE_FRAGMENTATION=0 (common on constrained MCUs — fragmentation requires heap allocation), _z_transport_tx_send_fragment() in src/transport/common/tx.c silently drops the message but returns _Z_RES_OK. The return value propagates all the way up through z_put() and z_publisher_put(), so the application sees success while the payload was never transmitted.
This is a silent failure: no error is returned, only an _Z_INFO log line that is invisible at default log levels.
Affected code
src/transport/common/tx.c, the #else branch compiled when Z_FEATURE_FRAGMENTATION=0:
static z_result_t _z_transport_tx_send_fragment(...) {
_ZP_UNUSED(ztc);
_ZP_UNUSED(n_msg);
// ...
_Z_INFO("Sending the message required fragmentation feature that is deactivated.");
return _Z_RES_OK; // payload was dropped — caller is told OK
}
This stub is reached from _z_transport_tx_send_n_msg_inner() whenever _z_network_message_encode() fails to fit the payload in the TX buffer and batch_has_data == false.
To reproduce
- Build zenoh-pico with
Z_FEATURE_FRAGMENTATION=0
- Call
z_put() (or z_publisher_put()) with a payload larger than Z_BATCH_UNICAST_SIZE
- Observe: return value is
0 (Z_OK) but no message is received on the subscriber
Expected behavior
z_put() should return a non-zero error code (e.g. _Z_ERR_TRANSPORT_NO_SPACE) so the caller can detect and handle the failure.
Proposed fix
Two-line change in the disabled-fragmentation stub:
// Before
_Z_INFO("Sending the message required fragmentation feature that is deactivated.");
return _Z_RES_OK;
// After
_Z_ERROR("Message exceeds transport batch size. Enable Z_FEATURE_FRAGMENTATION to send large payloads.");
return _Z_ERR_TRANSPORT_NO_SPACE;
_Z_ERR_TRANSPORT_NO_SPACE is already defined in result.h (value -98).
System info
Affects all platforms built with Z_FEATURE_FRAGMENTATION=0. Particularly impactful on constrained MCU targets (Arduino, Zephyr small configs, bare-metal) where fragmentation is often disabled to avoid heap dependency.
AI-assisted — authored with Claude, reviewed by Komada.
Describe the bug
When
Z_FEATURE_FRAGMENTATION=0(common on constrained MCUs — fragmentation requires heap allocation),_z_transport_tx_send_fragment()insrc/transport/common/tx.csilently drops the message but returns_Z_RES_OK. The return value propagates all the way up throughz_put()andz_publisher_put(), so the application sees success while the payload was never transmitted.This is a silent failure: no error is returned, only an
_Z_INFOlog line that is invisible at default log levels.Affected code
src/transport/common/tx.c, the#elsebranch compiled whenZ_FEATURE_FRAGMENTATION=0:This stub is reached from
_z_transport_tx_send_n_msg_inner()whenever_z_network_message_encode()fails to fit the payload in the TX buffer andbatch_has_data == false.To reproduce
Z_FEATURE_FRAGMENTATION=0z_put()(orz_publisher_put()) with a payload larger thanZ_BATCH_UNICAST_SIZE0(Z_OK) but no message is received on the subscriberExpected behavior
z_put()should return a non-zero error code (e.g._Z_ERR_TRANSPORT_NO_SPACE) so the caller can detect and handle the failure.Proposed fix
Two-line change in the disabled-fragmentation stub:
_Z_ERR_TRANSPORT_NO_SPACEis already defined inresult.h(value-98).System info
Affects all platforms built with
Z_FEATURE_FRAGMENTATION=0. Particularly impactful on constrained MCU targets (Arduino, Zephyr small configs, bare-metal) where fragmentation is often disabled to avoid heap dependency.AI-assisted — authored with Claude, reviewed by Komada.