Closed ydie22 closed 1 year ago
Hi @ydie22,
We've verified this bug and have already begun work on a fix. Stay tuned.
Bug has been fixed in https://github.com/Particular/NServiceBus.RabbitMQ/pull/1233 and released as NServiceBus.Transport.RabbitMQ.CommandLine 8.0.3. Here's the release notes and announcement.
This did result in a release of NServiceBus.RabbitMQ 8.0.3 as well, but that contains no code changes from version 8.0.2.
Thanks for the super quick fix! We could successfully migrate some queues without losing a single message.
Describe the bug
Description
When using the command-line tool to migrate to quorum queues, we experienced severe message loss. All but the first message from the source queue were lost.
Expected behavior
All messages from the source classic queue should be found in the newly created quorum queue.
Actual behavior
Only the first message can be found in the new queue.
Versions
nservicebus.transport.rabbitmq.commandline 8.0.1
Steps to reproduce
Use the tool to migrate a classic queue holding several messages. The migrated messages must contain the header NServiceBus.MessageId.
Relevant log output
No response
Additional Information
Workarounds
No known workarounds
Possible solutions
It appears that the
Headers
property on message basic properties is of typeIDictionary<string, object>
. The NServiceBus.MessageId is extracted, which yields an object, on whichToString()
is called. The runtime type of that object is howeverSystem.Byte[]
, andToString()
returns the type name, not the actual underlying string value of the header. The deduplication logic then incorrectly concludes that the message has already been migrated if it is not the first one.Additional information
Parameter order should be checked on calls to
channel.BasicPublish()
. Routing key and exchange name seem to be swapped (while this does not seem to break the expected publishing behavior).