Here's some feedback based on my experiences supporting ASP.NET Core and Dapr for .NET. These are just my opinions so feel free to ignore my ideas if they are a bit fit for what you're trying to accomplish.
It would be interesting to think about the right semantics here, and how your communicate status back to Dapr. I think the way this code is written there's no way for the framework to tell Dapr to drop a message. For example a message with invalid JSON will be retried up to the max retry count.
Content types
You should think about checking the content type. It's legal for pub/sub messages to have a non-JSON content type.
Error handling
You probably want to introduce some error handling here, or at least think about what should happen if a handler throws an error. What if there are multiple handlers?
If you do end up catching exceptions here, log them. In general M.E.Logging-enabled code should only log exceptions that it catches.
From @rynowak:
Here's some feedback based on my experiences supporting ASP.NET Core and Dapr for .NET. These are just my opinions so feel free to ignore my ideas if they are a bit fit for what you're trying to accomplish.
Pub/Sub responses
See the docs here about responses to pub/sub: https://docs.dapr.io/reference/api/pubsub_api/#expected-http-response
It would be interesting to think about the right semantics here, and how your communicate status back to Dapr. I think the way this code is written there's no way for the framework to tell Dapr to drop a message. For example a message with invalid JSON will be retried up to the max retry count.
Content types
You should think about checking the content type. It's legal for pub/sub messages to have a non-JSON content type.
Error handling
You probably want to introduce some error handling here, or at least think about what should happen if a handler throws an error. What if there are multiple handlers?
If you do end up catching exceptions here, log them. In general M.E.Logging-enabled code should only log exceptions that it catches.