Add typechecking to the Jaeger propagator - #5440
Conversation
…ator The function returns a 3-tuple (trace_id, span_id, flags) on every code path and callers unpack three values, but the annotation declared tuple[int] (a one-element tuple), which misleads type checkers.
75f22c1 to
9fcea30
Compare
|
Change looks good, any chance you can fix all the typing issue in the package so we can enable typechecking? Your PR already fixes half of them. Add the following and then |
Parameterize Getter/Setter with CarrierT to match the base class signatures, guard against None baggage values before unquoting, type header values as str instead of the unbound CarrierT, and make _int_from_hex_str return int | None with explicit fallbacks at the call sites. Add the package to the pyright include list.
Thanks for the review! Sure, I can do that. I've updated pyproject.toml to include the jaeger propagator, fixed the remaining typing issues, and made sure that uv run tox -e typecheck passes successfully :) |
|
please fix conflicts |
…ace-id-header-annotation
…ace-id-header-annotation
Pull request dashboard statusWaiting on the author · refreshed 2026-08-15 12:58 UTC Respond to 1 review item (e.g. link a commit, explain why not, ask a follow-up):
Status above doesn't look right?
|
Description
_parse_trace_id_headerin the Jaeger propagator is annotated as returningtuple[int](a tuple of exactly one element), but every return path yields a 3-tuple(trace_id, span_id, flags)and the caller unpacks three values. This misleads type checkers.This PR fixes the annotation to
tuple[int, int, int]. Annotation-only change, no runtime impact._extract_baggage— Add complete type annotationType of change
How Has This Been Tested?
Annotation-only change; existing
propagator/opentelemetry-propagator-jaegertests cover the extraction behavior.tox -e typecheck
Does This PR Require a Contrib Repo Change?
Checklist: