Skip to content

Comments

Implement Environment Variable Context Propagation carriers in api/in…#8074

Open
Bhagirath00 wants to merge 6 commits intoopen-telemetry:mainfrom
Bhagirath00:feature/env-var-propagation
Open

Implement Environment Variable Context Propagation carriers in api/in…#8074
Bhagirath00 wants to merge 6 commits intoopen-telemetry:mainfrom
Bhagirath00:feature/env-var-propagation

Conversation

@Bhagirath00
Copy link

Issue: #7992

This PR implements environmental variable context propagation by adding EnvironmentGetter and EnvironmentSetter carriers to the api/incubator module. This allows the Java SDK to extract and inject trace data through standard environment variables.

Changes

  • Added EnvironmentGetter to handle context extraction from environment variables.
  • Added EnvironmentSetter to handle context injection for child processes.
  • Implemented logic to ensure environment variable keys are handled in the standard uppercase format.
  • Added comprehensive unit tests to verify case-insensitive lookups and correct value extraction.

Terminal Screenshots

All new unit tests passed successfully.
image

Code has been formatted and passed style checks.
image

@Bhagirath00 Bhagirath00 requested a review from a team as a code owner February 12, 2026 12:55
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Feb 12, 2026

CLA Signed

The committers listed above are authorized under a signed CLA.

@codecov
Copy link

codecov bot commented Feb 12, 2026

Codecov Report

❌ Patch coverage is 96.87500% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.33%. Comparing base (fff95e0) to head (b8d7f67).
⚠️ Report is 25 commits behind head on main.

Files with missing lines Patch % Lines
...y/api/incubator/propagation/EnvironmentGetter.java 93.33% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #8074      +/-   ##
============================================
+ Coverage     90.20%   90.33%   +0.13%     
- Complexity     7592     7629      +37     
============================================
  Files           841      841              
  Lines         22911    22920       +9     
  Branches       2288     2286       -2     
============================================
+ Hits          20666    20704      +38     
+ Misses         1529     1506      -23     
+ Partials        716      710       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

return;
}
// Spec recommends using uppercase for environment variable names.
carrier.put(key.toUpperCase(Locale.ROOT), value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marking as unresolved because I don't see anything related to the restriction of characters to those that are valid in HTTP header fields, or explanation for how we should be thinking about the platform specific size limitations. Size limitations could be an optional config parameter, for example. Not sure.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I've added value validation for HTTP header field characters per RFC 9110 — the setter skips and the getter ignores values with invalid characters. For size limits, I've documented the platform-specific limits in the Javadoc for now since the caller controls how many entries go into the map. Let me know if you'd prefer something more like a configurable limit instead.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine for now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay

* TRACESTATE}, {@code BAGGAGE}). This setter translates keys to uppercase before inserting them
* into the carrier.
*/
public enum EnvironmentSetter implements TextMapSetter<Map<String, String>> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So where would this type of thing be used in practice? Since its just setting into a map, the only thing about it specific to env vars is the formatting of the keys.

The caller would have to be managing sub processes and need to manipulate their environment. Something like:

    Map<String, String> env = new HashMap<>();
    contextPropagators.getTextMapPropagator().inject(context, env, EnvironmentSetter.getInstance());
    ProcessBuilder processBuilder = new ProcessBuilder();
    processBuilder.environment().putAll(env);

Is this what you had in mind? Have any users asked for this or this just to be spec complete?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. I just wanted a simple way to make sure the keys get formatted correctly for environment variables (uppercase/underscores) without having to do it manually every time we use something like a ProcessBuilder.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me. Marking as unresolved just so it be a more visible explanation for why we have this, when we don't have any other built-in getter / setter implementations. (Its occasionally useful to come back to PRs and find the key comments.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a ProcessBuilder usage example and a clearer explanation directly in the Javadoc now, so future readers can see the purpose without digging through PR comments.

@Bhagirath00
Copy link
Author

Well i think Build are failing!!!

@Bhagirath00
Copy link
Author

@jack-berg Plz review!

@jack-berg
Copy link
Member

Please respond: #8074 (comment)

@Bhagirath00
Copy link
Author

@jack-berg Sorry for inconvenience!

@Bhagirath00
Copy link
Author

@jack-berg Updated the PR based on your feedback!!

Copy link
Member

@jack-berg jack-berg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of remaining nits. @adrielp any chance you could take a look and confirm this matches your expectations based on the spec?

@Bhagirath00
Copy link
Author

Plz update this Pr

// Spec recommends using uppercase and underscores for environment variable
// names for maximum
// cross-platform compatibility.
String sanitizedKey = key.replace('.', '_').replace('-', '_').toUpperCase(Locale.ROOT);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since EnvironmentGetter reads from the environment, keeping a copy, shouldn't this be toLowerCase instead of toUpperCase? Upper case I don't think will end up matching header values since the spec for w3c for example is traceparent not TRACEPARENT. environment variables in the environment should be uppercase, _ separated, but to auto be mapped to the w3c spec the normalized to lower.

Hopefully this makes sense, and hopefully I'm reading this right. I haven't touched Java in a long time.

@adrielp
Copy link
Member

adrielp commented Feb 21, 2026

Just a couple of remaining nits. @adrielp any chance you could take a look and confirm this matches your expectations based on the spec?

Thanks all for the work on this. I checked it out. Everything looks pretty good, I had one key question though about lower/upper case within the carrier.

@jack-berg
Copy link
Member

Just a couple of remaining nits. @adrielp any chance you could take a look and confirm this matches your expectations based on the spec?

Thanks all for the work on this. I checked it out. Everything looks pretty good, I had one key question though about lower/upper case within the carrier.

@adrielp now that you mention it, it's not possible for lossless round tripping as a result of both the case and the fact that both . and - are converted to _. Did this come up when landing the spec work?

@adrielp
Copy link
Member

adrielp commented Feb 23, 2026

@adrielp now that you mention it, it's not possible for lossless round tripping as a result of both the case and the fact that both . and - are converted to _. Did this come up when landing the spec work?

Can you elaborate more on that statement?

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.

3 participants