-
Notifications
You must be signed in to change notification settings - Fork 67
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
[SYNPY-1344] Remove need to manually propogate otel context #1056
[SYNPY-1344] Remove need to manually propogate otel context #1056
Conversation
Hello @BryanFauble! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2024-01-29 18:31:52 UTC |
Quality Gate passedThe SonarCloud Quality Gate passed, but some issues were introduced. 5 New issues |
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.
@BryanFauble On a high level, I prefer this over passing around the context manager. I haven't had the time to review closer, but this is great.
Can the team @Sage-Bionetworks/dpe pitch in on this review?
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 like this change. LGTM but just one question.
OpenTelemetry context to the thread or context that the function is running on. | ||
|
||
This is a hack to get around AsyncIO `run_in_executor` not propagating the context | ||
to the code it's executing. When we are directly calling async functions after |
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.
If we can remove this after SYNPY-1411 is complete, what does the difference between making this change now vs. later look like?
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.
Making the change to use this wrapper now prevents us from needing to modify the code in client.py
to manually propagate the OTEL context.
Making the change later means we will have had to propagate the OTEL to the rest of the sync methods we want to call in client.py
that haven't been called yet. And all those methods need to be changed back.
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.
Looks good, I really like the mixin for permissions. Only thing is permissions issues for the demo script. I'll come back and approve once I can run it.
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.
Looks good, I really like the mixin for permissions. Only thing is permissions issues for the demo script. I'll come back and approve once I can run it.
@BWMac Which would you prefer: The current way we are passing the context along (No change), or wrapping the calling side to handle for this (This change)?
Problem:
Because we are using
run_in_executor
to execute blocking code in an async context otel context is not propogating to the new code that is executing. As a result we were required to pass the context along and modify the functions to accept the parameter to make it work.Solution:
Creating a wrapper function that we can add to
run_in_executor
that attaches the otel context for us; prevents us from needing to modifying all of the sync code function signatures.Testing:
I verified I could run our OOP test scripts and all otel context remained: