dotnetcore / CAP

Distributed transaction solution in micro-service base on eventually consistency, also an eventbus with Outbox pattern
http://cap.dotnetcore.xyz
MIT License
6.61k stars 1.28k forks source link

Adding default publish headers #1498

Closed demorgi closed 5 months ago

demorgi commented 6 months ago

Description:

A case when you need to add specific custom header to each message - it's not possible at the moment. Added DefaultPublishHeaders dictionary that gets added to all published messages.

Changes:

Affected components:

Checklist:

Reviewers:

@yang-xiaodong @mviegas

mviegas commented 6 months ago

@demorgi I just remembered the following: wouldn't the current CustomHeaders property in AzureServiceBusOptions solve this issue without the need of extra code? Please check it here.

demorgi commented 6 months ago

@demorgi I just remembered the following: wouldn't the current CustomHeaders property in AzureServiceBusOptions solve this issue without the need of extra code? Please check it here.

@mviegas Correct me if I'm wrong but CustomHeaders are for inbound messages, just to support for other publishers outside of CAP (e.g. mass transit publishes a message, so now we need to configure CustomHeaders to injest it)

Here we are adding headers to outbound.

mviegas commented 6 months ago

You're completely right, it's been a while since I touched this feature. Apologies for the confusion.

LGTM

yang-xiaodong commented 6 months ago

I don't think this is a good feature. In our case, we need to add a dynamic TenantId as a header in each message. This new Option cannot achieve this. I think this requires the user to wrap Publish to add additional header information. Taking a step back, we need to provide a AOP feature for Publish similar to SubscribeFilter?

demorgi commented 6 months ago

@yang-xiaodong Let me explain it a little bit differently, so there are 2 ways you can get data to populate headers:

  1. From request pipeline, either from request payload or fetched from datastore or etc, all of this data is a part of request processing and is disposed once request is finished. You can get data from this request and post it to headers, as this data is dynamic there is no good way to automatically populate headers (unless we start doing some context magic with lambdas expressions and stuff). In this case you can just manually add header on message publish as it needs additional control (null checks and stuff)
  2. Data from environment variables, this one can be populated with this new dictionary. It can be used for message routing or provide additional host context for messages
demorgi commented 6 months ago

@yang-xiaodong thoughts? (If you haven't change your mind regarding this feature, we should close this PR)

yang-xiaodong commented 6 months ago

@demorgi I want to add a filter or something to support this feature in the future version, thanks for your PR!