Support receive properties of a message as headers

[SzymonPobiega]

Assumptions

• Each failed message processing attempt contains two data bags: headers and metadata metadata as a bag has been discontinued when implementing SQL persistence
• There is no place to plug in between transport receiver and ServiceControl message processor that can access ReceiveProperties
  • The closest potential option seems to an enricher but currently enrichers can only access headers, not receive properties
• The SP UI can visualize and edit headers but does not allow editing metadata
• SC transport customization can modify outgoing Azure Service Bus messages via OutgoingNativeMessageCustomization but the only source of input information are headers
• There is going to be few, if any, receive properties in most transports. Receive properties are transport-specific bits of information that we chose to make available at the level of NServiceBus. Not all information available on broker SDK types are going to become receiver/dispatch properties. Notable exception is the SQS transport which has a concept of attributes which can be custom-defined and are separate from NServiceBus headers when using the default envelope option

Selected alternative: Store properties as pseudo-headers

• Use unique header prefix e.g. ServiceControl.ReceiveProperties.*
• Store all receive properties when handling a failed message
• Set all dispatch properties when retrying
• SP UI allows changing the receive properties as headers

Consequences

• Does not require any changes to SP and minimal changes to SC (no changes in persistent data structures)
• Transports that do not have receive properties are not affected
• New properties are automatically set
• SP can be changed to recognize the ServiceControl.ReceiveProperties.* convention to distinguish the headers from the receive/dispatch properties
• Dispatch properties can be set at last moment when the message is send back to its destination queue (versus when it is sent to the staging queue) which seems to be a safer option

Alternative 1: Store session ID as a pseudo-header

• Extend the enricher API to allow receive properties as input source. SP public classes are not treated as public API so we can do it without releasing a major version
• Register an enricher using AddTransportForPrimaryCore extension point. Take the SessionId receive property and promote to "ServiceControl.NServiceBus.Transports.AzureServiceBus.SessionId" pseudo-header
• Allow users to modify this value using SP UI
• Register a customization using OutgoingNativeMessageCustomization. Take the value of the pseudo-header and use it to set the SessionId property

Consequences

• Does not change the stored data format
• Does not require any changes in SP
• The existence of the pseudo-header may be confusing. The UX is not great because we need to document that to change the session ID the user needs to manipulate the ServiceControl.NServiceBus.Transports.AzureServiceBus.SessionId pseudo-header
  • Assumption: OutgoingNativeMessageCustomization can remove headers from the SDK message to make sure the pseudo-header does not leak from ServiceControl
• Each new receive property would require similar feature to be handled

Alternative 2: Add another data bag to message processing attempt

• Read the properties when processing a failed message
• Allow the properties to be accessed for read/write via SP
• Build UI in SP to show/modify the properties
• Set the dispatch properties based on the stored values when retrying messages

Consequences

• A clean separation of responsibilities
• Fairly easy in RavenDB but complicated in SQL persistence, requiring another json field in the entity
• Requires significant work in SP to make the receive/dispatch properties editable

Alternative 3: Store properties as metadata

• Read the properties when processing a failed message and store in the metadata bag
• Set the dispatch properties based on the stored values when retrying messages
• Optionally build UI to modify selected metadata in SP
  • Can SC send the receive properties as pseudo-headers to SP so that they are visualized as headers?

Consequences

• Requires bringing back metadata bag in the SQL persistence, requiring another json field in the entity
• Requires significant work in SP to make the receive/dispatch properties editable