Support the IFeaturesCollection

[stevejgordon]

There may be value in registering something into the IFeaturesCollection such that downstream middleware can inspect the status of the correlation ID and make decisions based upon it. This feels like a reasonable use of that concept.

Today it's possible to grab the accessor and acting on the value directly but that may be less convenient for downstream middleware.

Useful metadata may include:

• Was a value provided by the caller?
• Was the value valid?
• Was the value generated by the library?

The most useful may be the valid/invalid case.

[tomkerkhove]

We use a similar approach: https://github.com/arcus-azure/arcus.webapi/blob/master/src/Arcus.WebApi.Logging/Correlation/CorrelationMiddleware.cs

That way it's super convenient for others, but you're locked in to the HTTP stack which is also a downside.

[k2ibegin]

Does correlation ID provide as good alternative to what Rebus correlation ID mechanism provides ? Can I also use this for non HTTP based worker microservices in combination with ASP NET core web api microservices ?

[stevejgordon]

@k2ibegin Your question would be best as a new issue since it's not really related to this one. I've not used Rebus to compare what that provides. This library is a simple option for a basic correlation header which can flow to downstream HTTP calls. You can apply this to non HTTP work but you need to link it together. We do this for AWS queues and we often attach the correlation ID as an attribute on the msg which we pull off at the other end. I have considering an integration package for that but it's fairly trivial code.