A NullReferenceException occurs when canceling a consumer (Library Version 6.8.1)

[Link9001]

Describe the bug

I have a setup with one RabbitMQ server (Version 3.13.7) and two clients (Version 6.8.1). One client manages the queues, while the other subscribes to them. When the second client attempts to cancel its consumers after the first client has deleted the queues, it throws a NullReferenceException.
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object. at RabbitMQ.Client.Impl.ModelBase.BasicCancel(String consumerTag) at RabbitMQ.Client.Impl.AutorecoveringModel.BasicCancel(String consumerTag) at Program.<Main>$(String[] args) in C:\Users\silbersm\Work\Repos\TestProjects\TestConsole\TestConsole\Program.cs:line 17

The workaround is to set the DefaultConsumer on the second client's model to any consumer instance.

Reproduction steps

Here are the steps to reproduce the behavior:

1. Start the RabbitMQ server.
2. Create two client connections and two models.
3. Use one model and connection pair to create a queue and subscribe a consumer.
4. The second pair then deletes the queue.
5. The first pair's model calls BasicCancel() with the consumer's tag.

A small .NET 8 test project is provided to reproduce this behavior consistently, containing the following files:

• csproj
• docker-compose.yml
• Program.cs

DemoProject.zip

I am using Windows 11 with Podman as my container runtime.

Expected behavior

I expect that the library can BasicCancel the consumer gracefully without exception.

Additional context

The exception is thrown when the ModelShutdown EventHandler is deregistered from the consumer that does not exist anymore.

[lukebakken]

Hello, thanks for using this library.

It seems like you know exactly what this issue is, and how to fix it. A pull request based on the 6.x branch would be very welcome. If you have time, attempting to reproduce this behavior using the latest version of this library would be greatly appreciated.

[Link9001]

A pull request based on the 6.x branch would be very welcome.

I would be glad to provide a PR if that's okay with you.

If you have time, attempting to reproduce this behavior using the latest version of this library would be greatly appreciated.

This exception will only happen in the latest 6.x Version of the Library. I tested with the latest 5.x and latest 4.x and there the RpcContinuation times out from the BasicCancel call. With the latest 7.x version, there are no errors at all.

[lukebakken]

I would be glad to provide a PR if that's okay with you

Please do that! Thank you for testing the 7.x version.