Describe the suggested improvement
Is your improvement related to a problem? Please describe.
Current behavior for incoming message context is that the incoming conversation ID is copied to each outgoing message. When only using NServiceBus this means that all incoming (nservicebus) messages will have the NServiceBus.ConversationId header
With native integration often do not have NServiceBus headers set. If such incoming message sends messages, the conversation would span the incoming + outgoing messages, but with current behavior all 3 messages will not share the same NServiceBus.ConversationId value.
A user CAN add a custom behavior to "enrich" these headers, but that requires that the user has intimate knowledge on how all these headers work in relation with the visualizations available in ServicePulse.
Describe the suggested solution
Resolve a deterministic NServiceBus.ConversationId for incoming messages, for example, use the incoming message ID as that should already be unique. All transports will use the transport native message ID as NServiceBus.MessageId
There is a slight gotcha. When the message is audited the headers will not have NServiceBus.ConversationId or even NServiceBus.MessageId set. Transports would need to have
Describe alternatives you've considered
Let all transport resolve more NServiceBus headers from native properties. This only feels right to actual native 1-1 mappings, not for secondary values. (i.e. native message ID -> NServiceBus.MessageId -> NServiceBus.ConversationId )
Messages received via https://github.com/Particular/NServiceBus.Envelope.CloudEvents are affected by this too. CloudEvents could add this behavior, but same as the transports, the fallback to use MessageID is more a Core concern than anything else.
Describe the suggested improvement
Is your improvement related to a problem? Please describe.
Current behavior for incoming message context is that the incoming conversation ID is copied to each outgoing message. When only using NServiceBus this means that all incoming (nservicebus) messages will have the
NServiceBus.ConversationIdheaderWith native integration often do not have NServiceBus headers set. If such incoming message sends messages, the conversation would span the incoming + outgoing messages, but with current behavior all 3 messages will not share the same NServiceBus.ConversationId value.
A user CAN add a custom behavior to "enrich" these headers, but that requires that the user has intimate knowledge on how all these headers work in relation with the visualizations available in ServicePulse.
Describe the suggested solution
Resolve a deterministic
NServiceBus.ConversationIdfor incoming messages, for example, use the incoming message ID as that should already be unique. All transports will use the transport native message ID asNServiceBus.MessageIdThere is a slight gotcha. When the message is audited the headers will not have
NServiceBus.ConversationIdor evenNServiceBus.MessageIdset. Transports would need to haveDescribe alternatives you've considered
Let all transport resolve more NServiceBus headers from native properties. This only feels right to actual native 1-1 mappings, not for secondary values. (i.e. native message ID ->
NServiceBus.MessageId->NServiceBus.ConversationId)Messages received via https://github.com/Particular/NServiceBus.Envelope.CloudEvents are affected by this too. CloudEvents could add this behavior, but same as the transports, the fallback to use MessageID is more a Core concern than anything else.