Skip to content

Conversation

YangJonghun
Copy link
Contributor

@YangJonghun YangJonghun commented Aug 19, 2025

Which problem is this PR solving?

This PR addresses compatibility issues with B3 propagator carrier handling across different language implementations. While other OTel language implementations use standardized B3 formats, the JavaScript implementation uses lowercase format, causing interoperability issues when traces cross language boundaries or when using non-HTTP transport methods.

Short description of the changes

  • Add fallback to lowercase header lookup in getHeaderValue function
  • Standardize B3 constants to proper case format (X-B3-*)
  • Improve compatibility with case-varying HTTP implementations

Type of change

  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • Injection now uses proper case format (X-B3-* instead of x-b3-*).
    • Extract handles both cases for backward compatibility.

How Has This Been Tested?

  • Existing unit tests continue to pass
  • Manual testing with different case combinations

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added

- Add fallback to lowercase header lookup in getHeaderValue
- Standardize B3 header constants to proper case format
- Improves compatibility with case-varying HTTP implementations
- Add inject test for proper case format validation
- Add extract tests for lowercase headers
- Add mixed case header extraction test
- Add priority test (standard case over lowercase)
- Add lowercase debug flag extraction test
@YangJonghun YangJonghun requested a review from a team as a code owner August 19, 2025 16:08
Copy link

codecov bot commented Aug 19, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.03%. Comparing base (8d0dcea) to head (ea432d7).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5859   +/-   ##
=======================================
  Coverage   95.03%   95.03%           
=======================================
  Files         306      306           
  Lines        7969     7969           
  Branches     1611     1612    +1     
=======================================
  Hits         7573     7573           
  Misses        396      396           
Files with missing lines Coverage Δ
...entelemetry-propagator-b3/src/B3MultiPropagator.ts 100.00% <100.00%> (ø)
...kages/opentelemetry-propagator-b3/src/constants.ts 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@YangJonghun YangJonghun changed the title feat(b3-propagator): implement case-insensitive carrier handling feat(b3-propagator)!: implement case-insensitive carrier handling Aug 20, 2025
@pichlermarc
Copy link
Member

+1 for extracting in a case insenstivie way from the carrier, but IIUC that should be done with a corresponding TextMapGetter for each instrumentation. For inejcting I'd prefer lowercase. From the B3 spec:

Note: Http headers are case-insensitive, but sometimes this encoding is used for other transports. When encoding in case-sensitive transports, prefer lowercase keys or the single header encoding which is explicitly lowercase.

Can you give an example which setup caused problems for you?

@YangJonghun
Copy link
Contributor Author

@pichlermarc
Thank you for the review.
I missed that part of the spec, and as you pointed out, it looks correct to remove the inject logic change and only handle extraction in a case-insensitive way. I appreciate you pointing that out.

I ran into issues when propagating trace context between Native (Android, iOS) and a WebView. In Swift and Java, the OTel B3Propagator implementations define the B3-related constants with camelcase, so they don’t recognize lowercase propagation.
Looking through the OpenTelemetry source, I noticed that some languages handle lowercase while others don’t, so it would be nice if this could be unified across implementations. 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants