Receive properties are lost on delayed retries - #7901
Merged
Conversation
* Preserve the native properties on delayed retries * Slightly better assertions hopefully * Align handler attribute usage with other tests since we forgot to change that --------- Co-authored-by: Daniel Marbach <danielmarbach@users.noreply.github.com>
lailabougria
approved these changes
Aug 5, 2026
danielmarbach
changed the title
This was referenced Aug 5, 2026
Open
Open
Open
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of:
Symptoms
When a message that carries native transport metadata via
ReceivePropertiesfails processing and is retried using delayed retries, the native receive properties are stripped. The metadata is present on the initial delivery but missing from the message once it is redelivered after the retry delay.For example, a transport that relies on native metadata such as a message group id or deduplication id would see those values on the first delivery and then lose them on every subsequent delayed-retry delivery.
Who's affected
Only transport authors who adopt the new
ReceivePropertiesAPI (introduced in NServiceBus 10.2.0 via #7662) to carry native message metadata through the pipeline are affected.End users of the Particular-supported transports are not affected, as no Particular transport currently uses the
ReceivePropertiesfeature.Root cause
Receive properties are propagated onto outgoing dispatch operations by
RoutingToDispatchConnector, but only when it can locate anIncomingMessagewith a matching message ID in the current context extensions.During a delayed retry, the recoverability pipeline creates an
OutgoingMessagewith the original message ID and dispatches it back to the input queue through the routing/dispatch pipeline. TheRecoverabilityContextalready held theReceivePropertiesas a direct property, but it never published anIncomingMessageinto its context extensions. Consequently, whenRoutingToDispatchConnectorlooked one up during the delayed-retry dispatch, the lookup failed, the receive properties resolved to empty, and the redelivered message shipped without its native metadata.The fix publishes the
IncomingMessage(carrying the receive properties) into the recoverability context extensions, so the metadata flows through the routing context into the dispatch stage and survives the delayed retry (#7900).