I have a producer writing messages to an Azure event hub, and a consumer reading the messages from the event hub. I upgraded the producer to .Net core, and in the process, switched from using the WindowsAzure.ServiceBus package to Azure.Messaging.EventHubs to write messages to the event hub.
Events from the old producer are still being processed with no problem. However, when the consumer receives any message from the new producer, I found an exception being thrown by the event processor, before my events get processed.
Unable to cast object of type 'System.Collections.Generic.List`1[System.Diagnostics.Activity]' to type 'System.Collections.Generic.IEnumerable`1[System.Diagnostics.Activity]'
This message is not displayed in the log output in Azure, but it does show up in Application Insights. The exception is not thrown when I run on my local machine.
This issue has been reported as a bug on the official Azure Functions EventHub repo. In the comments, users mention that the issue was introduced in version 4.1.0, and reverting to 4.0.1 fixed the issue.
I reverted to 4.0.1, and it stopped the exceptions from being thrown, but there is still a difference between the old messages and the new messages. I'm using Microsoft.Azure.Functions.Extensions for dependency injection. Whenever I receive a batch of entirely old messages, there is no problem. However, when I receive a batch containing new messages, the dependency injection scope has no services configured.
If I run the project locally, there is no issue. It is only when I deploy to the Azure Functions environment that I have these issues.
So far, I have:
- Deployed in debug mode instead of release
- Created a new Azure Function App and deployed fresh
- Changed the publish configuration from 'Framework Dependent' to 'Self Contained'
- Updated the publisher to use
Microsoft.Azure.EventHubs, so that the publisher and consumer are using the same package
I've tried to think of what might be different between my local environment, and the Azure Functions environment, for me to see a difference in behaviour.
Local:
- dotnet sdk 3.1.301
- dotnet runtime 3.1.7
Azure:
- dotnet sdk 3.1.302
- dotnet runtime 3.1.6
