Large messages causes channel to shut down

[2joocy]

We've got a production setup running where we've encountered an issue where the responses causes the server to shut down with the following error:

connection closed by server 505 UNEXPECTED_FRAME - expected content body, got non content body frame instead 60 40
amqp-client connection closed connection closed: UNEXPECTED_FRAME - expected content body, got non content body frame instead (505)
ERROR AMQPError: connection closed: UNEXPECTED_FRAME - expected content body, got non content body frame instead (505)

I've made a repo that replicates this issue consistently, under my profile: https://github.com/2joocy/cloudamqp-frame-issue The repo contains a very minimal example of sending a message from the same channel a couple times, causing the server to crash. You can edit the connection string to rabbitmq in app.ts. The only requirement is that you've run npm i and then run npm start with the correct connection string.

We've used an older library before and didn't have issues, I've set the same test up with https://www.npmjs.com/package/amqplib and the data passes through.

Is this an issue from the library side or should we handle messages differently? Or are there parameters to circumvent this?

[chadknutson]

Try adding the await operator for the publish statement in your code. That will prevent javascript from trying to send the next message before the first message's body is fully written to the socket. E.g., for (let index = 0; index < 3; index++) { await q.publish(data).catch(console.error); }

[2joocy]

Try adding the await operator for the publish statement in your code. That will prevent javascript from trying to send the next message before the first message's body is fully written to the socket. E.g., for (let index = 0; index < 3; index++) { await q.publish(data).catch(console.error); }

That's done on purpose to provoke the error. This error only happens when we load test the whole system, and the code I presented is just a simplification to provoke the same thing. With the await it works, however I tried to not include async sending from multiple clients to simulate the load testing that we do, just to keep the example project small. The data is also just mock data to fill around the same as the production data that is logged during the crash. Just as a note, in the production code we are awaiting the sends

const encrypted = encrypt(data);
const buffer = Buffer.from(encrypted);
await channel.basicPublish("", message?.properties.replyTo ?? "", buffer, publishOptions);

[dentarg]

I'll just note that I can still reproduce with amqp-client.js v3.0.0 (on both RabbitMQ 3.9.16 used in the example here and RabbitMQ 3.12.1).