I came across this issue as I was trying to hunt down a different potential issue in the library.
Normally, I would not bother the MQTT guys about a configuration issue,
except for the fact that the other potential issue also manifests itself when using large payloads.
So there may be an associated aspect (concerning client buffers) between this issue and the more serious potential issue that I am encountering.

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