-
Notifications
You must be signed in to change notification settings - Fork 5
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
Keep the tracer reference in the middleware itself #28
Conversation
Codecov Report
@@ Coverage Diff @@
## master #28 +/- ##
==========================================
+ Coverage 86.21% 88.15% +1.93%
==========================================
Files 8 8
Lines 283 287 +4
==========================================
+ Hits 244 253 +9
+ Misses 39 34 -5
Continue to review full report at Codecov.
|
starlette_zipkin/middleware.py
Outdated
if tracer is None: | ||
tracer = await init_tracer(self.config) | ||
if self.tracer is None: | ||
self.tracer = await init_tracer(self.config) |
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.
Here the _tracer_ctx_var
is not persisted between requests, so we still have to somehow to set it for every subsequent requests
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.
oh, ok! Got it. thanks
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.
@mchlvl
Now I really understand how it is supposed to works.
We keep the reference of the tracer in the middleware, and push it in the context on every requests.
And it is supposed to be works exactly like the root span.
As a better solution, one context var could be used for both variable because they are used together.
It was definitely not correct in 0.1.2, no doubt about that :D Thanks for making this proposal, looks good! Other than that one comment, I think the tests will need adjustment to properly use the tracer fixture |
412ab76
to
69acb22
Compare
No offense, It was just for explaining the whole context of the changes. I think it is ok now with this merge request. The example works fine. |
Is this branch ready for merge? If so, I'll do some tests asap. |
@mardiros neat! I noted the tests are soft complaning, but I think that should not block the functionality, so lets get this in 🎉 |
Manually tested. Traces look ok! 👍 |
So I checkout tag 0.1.2 and then tag 0.2 and your branch.
In 0.1.2, there where a ZipkinMiddleware.tracer attribute initialize on the init_tracer function
and it was initialized on the first dispatch
(I've also note that the tracer.close was an unreachable statement (not in finally) and thankfully because the tracer was not supposed to be closed.)
And, for SOLID principle, Ive move all the ContextVar manipulation in the trace.py module.
and the self.tracer was never initialized (and I should remove it completly.
From what I understand, event after and
init_tracer(self.config)
the get_tracer() return None and we reinit it ?If it is the case, I think we can keep the reference in the middleware instance like in this merge request.
I have to do more investigation to confirm that.