Transaction Context Propagation Proposal

[beeme1mr]

Relates to open-feature/spec#81

[toddbaert]

I think this makes a lot of sense, and could really help in applications without a robust dependency injection framework, or some other means of grabbing transaction-scoped data.

For example, in some multi-layered application, information about the subject (authenticated user) may only be available in the web layer. If a flag must be evaluated in some domain logic or data-access layer, it would require the application author to add the relevant user data down the entire call stack to where it's needed; adding an additional param to every called function on a huge function stack... Storing this data in a side-channel, such as thread-local storage or async continuations, allows this information to be passed to flag evaluations without this burden.

I'd like to see a PR adding this to the spec in a platform independent way.

[morigs]

Is distributed context propagation out of context?
As a developer, how can I extract the current context in order to send it further (for instance, using OTel Baggage)?
Perhaps this matter should be mentioned even if it's out of scope

[beeme1mr]

Hi @morigs, that's a good point. I'll explicitly state that distributed context propagation is out of scope of this OFEP. However, this OFEP is likely a prereq for distributed context propagation using OTel.

By the way, the demo environment includes a proof of concept for distributed context propagation. You can see it here.

[moredip]

I think this would be really beneficial for some runtimes (i.e. node), and is a really representative example of how the OpenFeature SDK could provide a very useful but fiddly-to-implement capability so that all the various providers don't have to figure it out themselves.

I would like to see if we could make the API as ergonomic as adding an attribute to an otel span - I think that's a close analog. Likewise it would be great it we could draw inspiration from how otel make the propagator registration as simple as possible for the simple case - maybe you've already done that.

[moredip]

@beeme1mr do you think you've gotten enough feedback on this that we could consider it accepted, and move on to speccing it out?