-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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