Closed Bobronium closed 1 year ago
Yeah that's fair. Since the ID is needed to propagate it to other services, it should be a part of the public API. In django-guid the second approach was used, but after using it for a while I'm not a huge fan of it tbh. I personally think approach 1 is simpler and has no real downsides.
Any thoughts on this @JonasKs?
The only reason to add a public API/helper functions on top of the contextvars are for newcomers I think. See threads on SO like this one, where the question is literally how to change the contextvar value.
I think it would be better to document how it’s implemented, and link to the docs for contextvars, than to wrap it. I know many people don’t look at package implementation, and contexvars can feel a bit magical.
I 100% vote for option 1. :blush:
.. sneaky edits.
Want to create a PR for this @Bobronium? 🙂
Currently one can
But it's unclear whether it's safe to rely on
asgi_correlation_id.context.correlation_id
since it's not added to the package's__init__
.Ways to address this
asgi_correlation_id.context.correlation_id
in package__init__
and add it to__all__
, explicitly making it a part of public interfaceget_current_correlation_id(default: Any = None) -> str | None
that returns current correlation_id and make it publicThe first approach allows full control over correlation_id, which may be not desirable. Second one only exposes getting part which is a lot safer.