arcus-azure / arcus.messaging

Messaging with Microsoft Azure in a breeze.
https://messaging.arcus-azure.net
MIT License
20 stars 11 forks source link

feat: use scoped message handlers via pumps/routers #397

Closed stijnmoreels closed 1 year ago

stijnmoreels commented 1 year ago

Enhances the current message handler registration by scoping any message handler registrations to a pump or router. This means that message handlers registered for another pump/router cannot be used during message routing.

This is a follow-up on the background jobs issue: https://github.com/arcus-azure/arcus.backgroundjobs/issues/200

The cool 😎 thing about this enhancement, is that it does not changes anything for single-message pump/router registrations; but changes the way we work with multiple pumps (which is the case when background jobs are involved).

Closes #395

netlify[bot] commented 1 year ago

Deploy Preview for arcus-messaging canceled.

Name Link
Latest commit 3a0881bcb507768ebeb460e962b924a60dd8cf16
Latest deploy log https://app.netlify.com/sites/arcus-messaging/deploys/64b8e1cf5d5fb6000887c24c
stijnmoreels commented 1 year ago

/azp run CI - Arcus.Messaging

azure-pipelines[bot] commented 1 year ago
Azure Pipelines successfully started running 1 pipeline(s).
fgheysels commented 1 year ago

This means that message handlers registered for another pump/router cannot be used during message routing.

What do you mean exactly ?

stijnmoreels commented 1 year ago

This means that message handlers registered for another pump/router cannot be used during message routing.

What do you mean exactly ?

In situations where you have two different message pumps/routers, the message handlers were previously shared among them. This PR makes sure that each set of message handlers is scoped to the pump/router; meaning that a message handler with the same message type will not 'wrongly' process a message that was meant for another pump/router. This is especially the case with background jobs, where you process 'events'; and pumps have the same event/message type to process.

fgheysels commented 1 year ago

This means that message handlers registered for another pump/router cannot be used during message routing.

What do you mean exactly ?

In situations where you have two different message pumps/routers, the message handlers were previously shared among them. This PR makes sure that each set of message handlers is scoped to the pump/router; meaning that a message handler with the same message type will not 'wrongly' process a message that was meant for another pump/router. This is especially the case with background jobs, where you process 'events'; and pumps have the same event/message type to process.

Ok thanks. But I would assume that this is something that could not ever happen, as the message handler is registered with a message-pump anyway ?

stijnmoreels commented 1 year ago

Ok thanks. But I would assume that this is something that could not ever happen, as the message handler is registered with a message-pump anyway ?

It seems that we do due to the code syntax, but behind the scenes they are all registered in the same dependency container. I succeeded in reproducing it by registering our two background jobs (auto-update secret in cache, auto-restart message pump), as they are both registered on 'secret new version created' events on Key Vault. This PR makes sure that your assumption that the code syntax proposes is reality behind the scenes.