Decrease max batch size in the stress tests #13953
Conversation
github-actions
bot
added
the
area: tests
Do you mean it will made permanent in the real code or test? |
|
Couldn't this be a problem in real scenarios as well (not just tests)? |
In the real code in the runtime. |
Probably but unlikely. Our scenario is already unsupported for large payloads. This issue will just make the container fail but with a different error. Still looking at the telemetry and trying to figure out if it shows up anywhere else.. |
no hits outside the stress tests. But yes, it is possible but highly unlikely (the stress tests use very badly compressed payloads explicitly to force chunking, hence it is happening more often) |
## Description Seeing some errors of the form: ``` Nack (BadRequestError): Message size too large. Boxcar message count: 1, size: 933394, max message size: 921600. ``` This is due to the fact that our max batch limit (if unspecified 972800) which will trigger chunking if exceeded is too high for the server-side limit of a message boxcar. What happens is that the batch gets compressed and the payload becomes 933394 bytes. 933394 < 972800, therefore chunking will not be activated. The payload is sent as-is and the server rejects it with the message above. **The default limit will also be made permanent in the runtime**
Description
Seeing some errors of the form:
This is due to the fact that our max batch limit (if unspecified 972800) which will trigger chunking if exceeded is too high for the server-side limit of a message boxcar.
What happens is that the batch gets compressed and the payload becomes 933394 bytes. 933394 < 972800, therefore chunking will not be activated. The payload is sent as-is and the server rejects it with the message above.
The default limit will also be made permanent in the runtime