-
Notifications
You must be signed in to change notification settings - Fork 818
envcar: ignore non-normalized env names on Get and Keys #9112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
pellared
merged 32 commits into
open-telemetry:main
from
pellared:env-var-get-keys-dont-normalize
Jun 25, 2026
Merged
Changes from all commits
Commits
Show all changes
32 commits
Select commit
Hold shift + click to select a range
a9d8b20
envcar: ignore non-normalized env names on Carrier.Get and Carrier.Keys
pellared 0d68660
add PR number
pellared a55d64e
Potential fix for pull request finding
pellared 4886024
skip some tests on windows
pellared da59bd7
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared c570540
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared d74740b
examples to restore the original value when it existed
pellared 651c756
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared f2dd0db
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared 6cb0baa
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared bec22d3
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared ca0cacf
avoid environment scan in Carrier.Get
pellared 5b1606f
add environment carrier operational guidance
pellared 0fedf62
handle empty env key normalization
pellared f57490e
isolate non-normalized env tests
pellared de3aca6
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared fd398ac
optimize caching
pellared c08dd30
git pushMerge branch 'env-var-get-keys-dont-normalize' of github.com:…
pellared 8c69898
rename cache
pellared 39c204e
update GoDoc
pellared c484525
refactor tests
pellared 591c0c3
fix TestCarrierKeys
pellared 060e0d3
optimize fetch
pellared 6a2ef55
add a note regarding Windows
pellared aeaccb0
Keys to read directly from environ
pellared ef3ca09
note that applications should extract context during startup
pellared 8da7802
improve GoDoc
pellared 19c35a0
refactor examples
pellared 9dcb3ef
improve example comments
pellared d7db01a
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared 9845fa3
Merge branch 'main' into env-var-get-keys-dont-normalize
pellared f15acc3
do not use SDK in ExampleCarrier_childProcess
pellared File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,22 @@ | ||
| // Copyright The OpenTelemetry Authors | ||
| // SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| // Package envcar implements the Environment Carrier specification as documented | ||
| // here https://opentelemetry.io/docs/specs/otel/context/env-carriers/ | ||
| // Package envcar implements the | ||
| // [Environment Variables as Context Propagation Carriers specification]. | ||
| // | ||
| // Environment variable propagation is intended for process boundaries where | ||
| // network protocols are not available, such as batch jobs, CI/CD, and command | ||
| // line tools. Treat context-related environment variables as process-startup | ||
| // input. | ||
| // | ||
| // Applications should extract context from the environment once during startup | ||
| // and then use the extracted context. Repeated extraction uses the process | ||
| // environment as a live parent-context source and may observe later environment | ||
| // variable changes. | ||
| // | ||
| // Note that environment variables can be visible to code in the same process | ||
| // and, on many systems, to other users or processes with sufficient | ||
| // permissions. Do not use this carrier for sensitive context. | ||
| // | ||
| // [Environment Variables as Context Propagation Carriers specification]: https://opentelemetry.io/docs/specs/otel/context/env-carriers/ | ||
| package envcar // import "go.opentelemetry.io/contrib/propagators/envcar" |
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the change back from store on first call? The Carrier was not supposed to (potentially) return different values for the same key, see the original PR for discussions on this.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check this discussion #9112 (comment)
This is also a related PR open-telemetry/opentelemetry-specification#5166
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Long story short the appropriate usage is to use this carrier once near application startup.
Caching and enumeration causes unnecessary overhead that we want to avoid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I unresolved the mentioned thread so that you can navigate to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean that Keys and Get can respond differently (if used contra to that startup expectation). Shouldn't we drop the store behaviour for Keys too? If the expectation is basically only one call to Keys ever then the store is pretty pointless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get wanting to avoid enumerating all environment variables for efficiency, however
Getnow reads directly from the env vars.The mutability of env vars is a concern of mine and I worry that reading directly from env vars without a cache could lead to unpredictable runtime bugs (eg. when an instrumented process emits several spans using the env var context as parent context and the vars were changed in between). Even instantiating the carrier once during startup would not protect against this.
The more I think about it, the more I want to add normative language to the spec like:
Get MUST NOT return different values when called with the same argumentimplying the use of a cache.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Joibel, @kamphaus, thanks a lot for your questions/concerns. These are exactly the discussions that we need to have before going RC.
@Joibel, I agree that
KeysandGetshould have the same observation model. If the expected usage is extracting once near startup, thenKeyswill typically be called at most once for that extraction path (e.g. when using https://pkg.go.dev/go.opentelemetry.io/contrib/propagators/ot which is the only known propagator that usesKeysmethod).Removing the
Keyscache also seems consistent with the current intended usage, and I think it would avoid the confusing case whereGetis live butKeysis a snapshot. It also looks fine for your vendored carrier usage here: https://github.com/argoproj/argo-workflows/blob/4cb7eb4e89299595ba8fddd3b7f9d95872c3b39d/workflow/executor/tracing/tracing.go#L26.Addressed aeaccb0
Just to double-check. Would you see any benefit from caching
GetandKeys, or would it just be unnecessary state/overhead?@kamphaus, agreed that construction alone would not protect against later environment mutation. What I meant is that applications should extract from the environment once during startup and then use the extracted context, rather than repeatedly using the process environment as a live parent-context source.
Addressed ef3ca09
@kamphaus, I do not think we have evidence yet that this is something which needs to be normative.
For OTel Go, C++ and Rust, we usually care very much about any overhead, I think it is fine if we can expect users to not call
Getmore than once for the same argument.At the same time, I think that for some languages it may be fine to cache. But maybe even for these languages it should be opt-in as it cause overhead that users may not want.
At this point of time, I lean towards the non-normative proposal from open-telemetry/opentelemetry-specification#5166
I do not take this lightly and I plan to further discuss this with maintainers of other language implementations.
@Joibel, WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this needs to be discussed with other language maintainers and thank you for taking this seriously.
Might I suggest in the meantime to document in the godoc that applications using envcar/Carrier should cache the context based on it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this before I read your comment 😉
PTAL ef3ca09
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I reviewed it before seeing this.