Nservicebus: Preserving native (transport) message ID

[SeanFeldman]

Context

When an NServiceBus endpoint sends a message, the message sent might have two message IDs:

1. A native message ID (from the underlying transport infrastructure)
2. And NServiceBus message ID expressed by NServiceBus.MessageId header.

Issue

When there's a need to investigate what happened to processed or failed messages, there are audit and error messages. Unfortunately, those messages contain NServiceBus message ID only and have no reference to the native message ID of the processed messages, which are often required by the infrastructure provider to identify what happened to the original message. Access to the native message ID is not possible in Core as the message ID is replaced with NServiceBus.MessageId headers' value upon the physical message injection prior to the IIncomingPhysicalMessageContext invocation. This context, while exposing IncomingMessage, has no longer access to the native message ID as it's lost during IncomingMessage construction.

Suggestion

Allow access to the native message ID by adding it to the headers or expose another way to access that value. E.g. add a property to IncomingMessage to expose native message ID.

[ramonsmits]

@SeanFeldman So ASB does set the transport value in the header but core overwrites the value? Would it be possible to add a behavior before that process that would clone the value to a header value using a different key?

[andreasohlund]

No, the transport passes it via the message context

https://github.com/Particular/NServiceBus/blob/master/src/NServiceBus.Core/Transports/MessageContext.cs#L45

and core only uses it if there is no message id header present

https://github.com/Particular/NServiceBus/blob/master/src/NServiceBus.Core/Transports/IncomingMessage.cs#L31

[SeanFeldman]

and core only uses it if there is no message id header present

Which is never the case if the message is sent by NServiceBus endpoint. Hence this issue 🙂

[RiaanVR]

Hi @andreasohlund and @SeanFeldman, how can we move this further, what is required before someone can pick it up?

[SeanFeldman]

Hi @RiaanVR, I've pinged internally to see how this could be addressed. Please be aware that this change is not a single transport change and therefore might require some internal alignment to be released.

Could you please let know what transport you're using and what's the issue you're experiencing that requires native message ID? Thank you.

[SeanFeldman]

@RiaanVR could you let know what transport are you using?

[RiaanVR]

@SeanFeldman sure sorry for the delay.
Currently we're using ServiceBus on Azure on a premium namespace, the reason for the feature is mostly for debugging purposes, we've had issues with the transport on the Azure side but also we've had problems while migrating to the new transport package, and having access to the native messageId allows for debugging on both sides

[fcastellscha]

Adding a clarification just in case. In the past we had an incident with
messaging where the root cause seemed to be the Service Bus namespace
itself. We had the affected NServiceBus MessageIds, but Microsoft Support
could not find the messages in their logs because they don't log the
message properties nor the content. They need the actual native message Id
to provide any meaningful support.
To be able to get this support when we have a production incident is
critical for us, therefore being able to log the native message Id (or find
it in the Audit messages) is also critical.

I hope it makes sense.

[SeanFeldman]

@RiaanVR, @fcastellscha the fix will be deployed with NServiceBus 7.2.0.
IncomingMessage will have NativeMessageId property which you'll be able to log or promote to a customer header. Thank you for your patience.

[fcastellscha]

That's excellent news. Thanks

On Wed, 2 Oct 2019 at 04:23, Sean Feldman [e-mail] wrote:

@RiaanVR https://github.com/RiaanVR, @fcastellscha
https://github.com/fcastellscha the fix will be deployed with
NServiceBus 7.2.0.
IncomingMessage will have NativeMessageId property which you'll be able
to log or promote to a customer header. Thank you for your patience.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/5391?email_source=notifications&email_token=AH6GO7XMECXFICUASU6RPFDQMQA2ZA5CNFSM4HVYSNH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADKVKI#issuecomment-537307817,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH6GO7WLN522G6HKTAWW3MDQMQA2ZANCNFSM4HVYSNHQ
.

--
Francesc Castells
Software Architect, Backend Tech Lead
Chama - Amsterdam Office

[RiaanVR]

@SeanFeldman thank you! Great news, do you have a timeline for the release of 7.2.0?

[SeanFeldman]

We don't have a specific date, but within a few weeks should be out. Assuming the release is passing all verifications. The best way to know the release went out is to subscribe to the forum, track the milestone, or subscribe to the release notifications in the repository.

[SeanFeldman]

7.2 has been released with this fix.
https://discuss.particular.net/t/nservicebus-7-2-0-minor-release-available/1445

[fcastellscha]

That's excellent news. We were also waiting for this one "Add discard as an
option for custom recoverability policies"

Thanks

On Thu, 24 Oct 2019 at 19:09, Sean Feldman [e-mail] wrote:

7.2 has been released with this fix.

https://discuss.particular.net/t/nservicebus-7-2-0-minor-release-available/1445

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/5391?email_source=notifications&email_token=AH6GO7QBP3C6MYC5SGJHNZLQQHJDHA5CNFSM4HVYSNH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECFYDSQ#issuecomment-546013642,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH6GO7QFIEQQQLTBG6ZNTZDQQHJDHANCNFSM4HVYSNHQ
.

--
Francesc Castells
Software Architect, Backend Tech Lead
Chama - Amsterdam Office

[SeanFeldman]

Both were shipped in 7.2 🙂

[fcastellscha]

Yeah, I saw it. That's why we are double happy for this release.

On Tue, 29 Oct 2019 at 17:37, Sean Feldman [e-mail] wrote:

Both were shipped in 7.2 🙂

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/5391?email_source=notifications&email_token=AH6GO7WAJ6HBOQGVKN5LMC3QRBRFHA5CNFSM4HVYSNH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRGXKA#issuecomment-547515304,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH6GO7XEQ6PWVQRLGRLY6E3QRBRFHANCNFSM4HVYSNHQ
.

--
Francesc Castells
Software Architect, Backend Tech Lead
Chama - Amsterdam Office