"Dead Letter Queue" for Notifications

[dstutz]

After browsing through the closed Issues I see this comment from you on "Get notification handler name inside Notification.Middleware" (https://github.com/sizovs/PipelinR/issues/18#issuecomment-907658132):

There is no way to achieve this with Middlewares because Middlewares don't know which Handlers will be handling the Notification. This is because a Notification Handler is just another Middleware that runs after all custom Middlewares (and all Middlewares are independent of each other).

So I'm going to assume it isn't possible to add functionality to have an unhandled notification or DLQ for notifications or is there a possibility for such feature?

[sizovs]

Hi @dstutz

Nice to e-meet you! Please describe your use case in more detail, and we'll see if PipelinR supports it natively, and if not, how to implement it otherwise.

[dstutz]

Hello again (I've been here before). My use case is catching misconfiguration/developer oversight by being aware of the situation when a notification goes unhandled (has no registered Notification.Handler in the pipeline). Similar concept to Guava EventBus DeadEvent that you can subscribe to. I've had situations where, for example, I forgot an @Inject on a ctor so the handler didn't get instantiated and picked up by CDI container and added to the pipeline.

[sizovs]

@dstutz Got it! PipelinR doesn't know if notification is unhandled because of a misconfiguration or intentionally (e.g., because the matches() method in Notification.Handlers returns false due a business condition). To prevent the configuration issue you mentioned, you can create an ArchUnit rule to verify that each notification has at least one corresponding handler.

Alternatively, you can create an abstract notification handler that will do something upon initialization – such as writing a log statement ("Hello, I am handling notification X"), incrementing thread local atomic counter (number of handlers per notification type), or exposing a metric. And then you have an integration test that verifies that there is at least one handler defined for each notification. However, I don't think the solution justifies the problem. As long as you write integration tests (and use ArchUnit as suggested above), the misconfiguration shouldn't get unnoticed (and leak into prod).

[dstutz]

Fair enough. Thank you for the information.