You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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....)
When one configures event listeners for a queue event:
and
FooListener
isn't registered to the DI container, the queue silently breaks when attempting to queue an invocable with the listener, inQueue::TryDispatchEvent
. The dispatcher attempts to create a listener but fails with nothing reported, even with a logger attached to the queue viaOnError
.I would expect the exception here to be surfaced somehow.
This is possibly related to needs communicated in #142 and #148, but not entirely.
The text was updated successfully, but these errors were encountered: