Feature Request: Async Notifications Delegates

[gbiellem]

The Notifications delegates aren't async in NSB 7.1.x
Would like to see this move to async in a future version

[DavidBoike]

Hi Greg! Good to hear from you!

This seems like something we can tackle with our (fairly new) enhancement release process. I've labeled it as an Enhancement so it can get picked up by that, but it will likely get more thoroughly triaged when its turn comes up.

[SimonCropp]

@DavidBoike how often does this triage happen?

[DavidBoike]

That's a good question. Best I can say is "it depends." We're trying to cycle through repos, and as you know Core is a bit of a unique animal.

[timbussmann]

@gbiellem I assume you refer to the error notifications (https://docs.particular.net/nservicebus/recoverability/subscribing-to-error-notifications?version=core_7.2), is that correct? Given those are .net events and you can use async void on them, is there a specific reason you'd like to see them being async?

[gbiellem]

@timbussmann True, async void is an option but I'd prefer a task based API rather than doing fire and forget using async void and have to deal with all the issues around it.

[timbussmann]

@gbiellem can you describe what type of code you're running as part of those notifications that fire&forget is not a good option for you? What types of issues are you referring to?

[SimonCropp]

@timbussmann with fire and forget... wont that cause potential issues with scoping of the container for things that are unit of work. ie the UOW could end while some things in the task still need them. Also how are dangling tasks handled when the endpoint is shutdown

[timbussmann]

yeah the child container scope could be disposed during an async void callback, that's true. Are you resolving scoped services in your event handlers?

Internally, we already have a task-based notifications API, I'm currently looking into exposing this for public usage.