Thanks for your post. We did fix a chunked publish issue since the v1.9.0 release:
https://github.com/wolfSSL/wolfMQTT/pull/230

Would you mind checking with the latest revision from GitHub? If the issue persists, we can open an issue for better tracking.

Thanks,
Eric @ wolfSSL Support

Back to this issue:
I was testing the new non-blocking "Publish Continue" feature in the MQTT v1.9.0 release.
This feature allows the application to identify when more tx data is pending for transmission to the network.

Some buffer sizes were changed to help invoke the new feature.
1. network maximum tx size  (defined by application stacks)
2. client tx buffer length        (defined by library's MAX_BUFFER_SIZE)
3. publish payload size          (test publish message, with a large amount of data)

The full transfer size is mqtt header (40bytes) + payload (2000 bytes).

Summary of investigation:
Net size   Buf len   Payload   Transfer sequence
1024       1000      2000      1000 + 1000 + pubContinue + 40
1000       1000      2000      1000 + 1000 + pubContinue + 40
980         1000      2000      980 + 20 + 980 + pubContinue + error(-2)

With certain buffer sizes and large payload sizes, the library returned error (-2), created at line 155 in the mqtt_socket.c file.
I retested the above conditions with the MQTT v1.8.0 library, which also exhibited the same results (with pubContinue replaced with the normal Continue).

The simple solution is to ensure that the "Network Tx Size is large enough to consume the entire Client Buffer Size".
It could be a Feature Request, but I doubt if it is really worthwhile modifying the library to deal with the small "Network Tx Size" case.

So this post is just an Advisory Note for users to "carefully" configure their system with this aspect in mind, when sending large payloads.
Kelvin