Delivery body corruption after upgrading from 5.1.0 to 6.8.1

[joaoantunesvisma]

Describe the bug

After upgrading from RabbitMQ.Client 5.2.0 to 6.8.1, BasicDeliverEventArgs.Body.ToArray() returns corrupted data containing binary garbage and/or truncated content under high load conditions in production. The corruption only occurs under high message throughput and never in local/staging environments.

Reproduction steps

1. Upgrade from RabbitMQ.Client 5.2.0 to 6.8.1 in a .NET 8 application
2. Deploy to production environment with high message throughput and concurrent consumers
3. Use the following code pattern to process messages:

private Message DeserializeMessage(BasicDeliverEventArgs bdea)
{
    var rawBytes = bdea.Body.ToArray();
    var serializedMessage = Encoding.UTF8.GetString(rawBytes);
    Message message;

    try
    {
        message = JsonConvert.DeserializeObject<Message>(serializedMessage);
    }
    catch (JsonReaderException ex)
    {
        SystemLog(LogLevel.Error, "JSON Error: {Error} at path '{Path}'. Full content: {Content}",
        null, ex, ex.Message, ex.Path ?? "unknown", serializedMessage ?? "null");
        throw;
    }

    return message;
}

4. Process messages under high concurrent load
5. Observe JSON deserialization failures with corrupted content

• ✅ High production load with concurrent consumers
• ✅ Multiple message processing happening simultaneously
• ❌ Never occurs in local/staging environments with low traffic
• ❌ Never occurred with RabbitMQ.Client 5.2.0 under same conditions

Expected behavior

BasicDeliverEventArgs.Body.ToArray() should return clean, valid message bytes that can be properly deserialized as JSON, just like it worked perfectly in RabbitMQ.Client 5.2.0 under the same conditions.

Additional context

Environment:

• RabbitMQ.Client: 6.8.1 (upgraded from 5.2.0)
• Framework: .NET 8
• Deployment: Production Kubernetes with high message throughput
• Scope: Only fails in production under load, works perfectly in local/staging

Breaking change context:

// 5.x - worked perfectly
public byte[] Body { get; set; }

// 6.x - introduces corruption
public ReadOnlyMemory Body { get; set; }

Corruption examples observed:

1. Binary prefix contamination

Content: ��n��s���|�q�v��5W�쿨��i�}�Z�"��x����...
Error: Unexpected character encountered while parsing value: . Path '', line 0, position 0

2. Message truncation at specific positions

Content: {"id":"test","data":"..."} [TRUNCATED AT POSITION 285]
Error: Unterminated string. Expected delimiter: ". Path 'url', line 1, position 285

3. Mixed binary/valid JSON content

Content: �˯^�k��@ct��C���p:�ܔ�...:"application/x-www-form-urlencoded","webHookType":7}
Error: Unexpected character encountered while parsing value: . Path '', line 0

Migration context:

This issue is blocking our planned migration path from 5.x → 6.x → 7.x. We chose incremental upgrades to minimize risk, but the corruption in 6.x is preventing progress. We're currently stuck on the upgrade.

Any guidance on root cause, workarounds, or recommended migration path would be greatly appreciated.

[michaelklishin]

@joaoantunesvisma 6.8.x is supported on the best effort basis. We need a way to reproduce this behavior, not a few lines of code.

In 7.x, there are explicitly documented Consumer Memory Safety Requirements and IIRC it could have already been the case in 6.8.x:

Important: consumer interface implementations must deserialize or copy delivery payload
before delivery handler method returns. Retaining a reference to
the payload is not safe: the memory allocated for it can be deallocated
at any moment after the handler returns.

[michaelklishin]

// 6.x - introduces corruption
public ReadOnlyMemory Body { get; set; }

Oh, there you go. Consumer Memory Safety Requirements is what you are after.

I cannot tell from the code snippet whether the handler already returns by the time the deserialization code runs but it's almost certainly a documented behavior and the price everyone has to pay for the benefits of using ReadOnlyMemory.

[joaoantunesvisma]

Thanks for the quick feedback! 🙏
I’ll review the Consumer Memory Safety Requirements more carefully, but as far as I can tell I was already copying the payload in synchronous code before using it.

I’ve also updated directly to 7.1.2, and so far I’m not seeing these errors anymore.

[michaelklishin]

Given that all focus of the tiny maintainer team is on 7.x (and beyond), I guess that settles the debate until someone who needs to use specifically 6.8.x steps up to investigate :)