Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registering event listeners that are not configured causes silent exceptions #304

Open
hammypants opened this issue Aug 15, 2022 · 1 comment

Comments

@hammypants
Copy link

hammypants commented Aug 15, 2022

When one configures event listeners for a queue event:

...
var registration = provider.ConfigureEvents();

registration
	.Register<QueueTaskStarted>()
		.Subscribe<FooListener>();
...

and FooListener isn't registered to the DI container, the queue silently breaks when attempting to queue an invocable with the listener, in Queue::TryDispatchEvent. The dispatcher attempts to create a listener but fails with nothing reported, even with a logger attached to the queue via OnError.

I would expect the exception here to be surfaced somehow.

This is possibly related to needs communicated in #142 and #148, but not entirely.

@jamesmh
Copy link
Owner

jamesmh commented Aug 20, 2022

I did a quick spike on this last night, but I forgot that there are built-in events that may or may not have listeners available in the service container... which is okay and expected.

So, the problem here is that if I implement some exception handling/throwing I have to explicitly know which events I shouldn't throw for (basically a whitelist).

Simple quick-and-dirty solution would be just to build a whitelist (like a List<>) and test against that to know whether the code should throw or not. But these are the kinds of decisions that can come to bite you in the butt later due to unknown crap or forgetting about some other thing.

I'm just going to mull on this - is there another way to do this? Perhaps add a "debug" or "strict" mode that can be turned on/off? Or perhaps #148 is enough? (I'm thinking that #148 would just solve this altogether....)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants