Transaction Context Propagation Proposal#32
Conversation
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Co-authored-by: Todd Baert <toddbaert@gmail.com> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Co-authored-by: Evan Bradley <github@evanbradley.org> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Co-authored-by: Evan Bradley <github@evanbradley.org> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Co-authored-by: Evan Bradley <github@evanbradley.org> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
There was a problem hiding this comment.
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.
Co-authored-by: Todd Baert <toddbaert@gmail.com> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Co-authored-by: Todd Baert <toddbaert@gmail.com> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Co-authored-by: Todd Baert <toddbaert@gmail.com> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
|
Is distributed context propagation out of context? |
|
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. |
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
|
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. |
|
@beeme1mr do you think you've gotten enough feedback on this that we could consider it accepted, and move on to speccing it out? |
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Relates to open-feature/spec#81