Integrate Arcus.Observability in MessagePumps for automatically logging request

[fgheysels]

I think it would be a good idea if we make sure that a MessagePump logs a request (using Arcus.Observability) whenever a message is retrieved / processed from the underlying servicebus.
Of course, this also implies that it must be possible for the user of Arcus.Messaging to define some configuration-options as in: where can I find an ID in the message that I've received that must be used for correlation, etc...

Or, do you think this is the responsability of the MessageHandler ? But in that case, it is the developer of the specific MessageHandler that has the responsability of making sure that a ServiceBus request is logged (which might mean repeated code).

[stijnmoreels]

I think this is already proposed here: #221 , but indeed, without yet configuration. Maybe that's then an improvement? I think, for now, the PoC already gives some guidance as to where this information is located. the ServiceBusReceivedMessage has already a correlation ID default property, too. But yeah, could/should be configurable later.

[fgheysels]

I think the 'configuration' part is mandatory, as afaik you cannot rely on a default header where you could look for the dependencyId.
The component that creates and posts the message to the service-bus will most likely add an additional 'user property' to the message which contains the dependencyId (correlation-id) that must be used by the component that processes the message to correlate the request.

Right now, the Service-to-Service PoC logs the request, but without specifying the dependency-Id:

source

I'd say that , in real life, there is some kind of 'agreement' between message producer and message consumer on where to find the Id that can be used for correlating dependencies & requests. So, the message consumer will need to specify somewhere in his code where / how to retrieve that Id from the message.

[stijnmoreels]

Now the dependency ID is retrieved back in the .GetCorrelationInfo extension on the Azure Service Bus Message. OperationParentId.
Indeed, should all be configurable.

[fgheysels]

We can consider moving the request tracking to the message router as there is no message pump when using the functionality in Azure Functions. Also mentioned in #221

I've been through some of the documentation and the code. I wouldn't say we can consider to move this request tracking to the MessageRouter, I think it is a given to have this request tracking implemented in the MessageRouter :).
Should this be defined in the MessageRouterOptions type ?

OTOH, I think Azure Functions will already log the request ?

[stijnmoreels]

I've been through some of the documentation and the code. I wouldn't say we can consider to move this request tracking to the MessageRouter, I think it is a given to have this request tracking implemented in the MessageRouter :).
Should this be defined in the MessageRouterOptions type ?

Hihi, yeah 😄 .
Yep, that is I think a good place for this.

OTOH, I think Azure Functions will already log the request ?

Well, hmm, maybe, but if we custom configure the dependency ID in a custom defined HTTP header/Azure Service Bus user property, I don't know if the built-in request tracking will be able to be configured to pick that up?

[stijnmoreels]

Done in #266