fix(api): handle null context in Baggage.fromContext and fromContextOrNull - #8666
fix(api): handle null context in Baggage.fromContext and fromContextOrNull#8666Solaris-star wants to merge 1 commit into
Conversation
…rNull Baggage.fromContext(null) and Baggage.fromContextOrNull(null) threw NullPointerException because both dereferenced the supplied Context without a null guard. This is inconsistent with Span.fromContext and Span.fromContextOrNull, which already log via ApiUsageLogger and return a safe fallback (getInvalid() / null). Apply the same pattern: - fromContext(null) logs and returns Baggage.empty() - fromContextOrNull(null) logs and returns null Adds two tests covering the null-context paths. Fixes open-telemetry#8665
|
Pull request dashboard statusClosed · refreshed 2026-07-28 15:27 UTC Status above doesn't look right?
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8666 +/- ##
=========================================
Coverage 91.46% 91.46%
- Complexity 10456 10459 +3
=========================================
Files 1021 1021
Lines 27647 27653 +6
Branches 3242 3242
=========================================
+ Hits 25288 25294 +6
Misses 1616 1616
Partials 743 743 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Hey @Solaris-star, I found and raised this issue and did work on it in #8667. Could you please close this PR to avoid duplicate work? Thank you for understanding! |
|
Come on. I can see you know how to use an LLM. And its clear based on the fast turnaround that you're scanning for simple well scoped issues to point your tokens at. Believe it or not, racing to solve trivial issues nobody has actually encountered in the wild isn't actually helpful and doesn't earn you good will from maintainers. If you really want to help in OSS, the critical path - the thing that's needed most and that people want to do the least - is code review. |
|
You're right — closing in favor of #8667 by the issue author (@NithinU2802). Apologies for the duplicate; I should have checked that the reporter was already working on a fix before opening this. Deferring to #8667. |
|
Fair point, and thank you for saying it directly rather than just closing it. You're right on both counts: I should have checked that the issue reporter was already working on a fix before racing to open this, and grabbing well-scoped trivial issues isn't where the real value is. I've closed this in favor of #8667. The code-review point is well taken — that is the unglamorous critical path, and I'll take it seriously rather than just optimizing for easy merges. |
Summary
Fixes #8665
Baggage.fromContext(null)andBaggage.fromContextOrNull(null)threwNullPointerExceptionbecause both dereferenced the suppliedContextwithout a null guard. This is inconsistent withSpan.fromContextandSpan.fromContextOrNull, which already log viaApiUsageLoggerand return a safe fallback.Fix
Apply the same pattern used by
Span:fromContext(null)→ logs viaApiUsageLogger.logNullParamand returnsBaggage.empty()fromContextOrNull(null)→ logs viaApiUsageLogger.logNullParamand returnsnullTests
Added two tests in
BaggageContextTest:fromContext_null— assertsBaggage.empty()is returnedfromContextOrNull_null— assertsnullis returnedNote: I could not run the Gradle build locally (no Java runtime on this machine), but the change is a direct copy of the established
Span.fromContext/Span.fromContextOrNullnull-handling pattern in the same codebase.