19
19
+ [ Process Spawning] ( #process-spawning )
20
20
+ [ Security] ( #security )
21
21
+ [ Case Sensitivity] ( #case-sensitivity )
22
+ - [ Supplementary Guidelines] ( #supplementary-guidelines )
23
+ * [ Approach 1: Providing a dedicated ` EnvironmentContextPropagator ` ] ( #approach-1-providing-a-dedicated-environmentcontextpropagator )
24
+ * [ Approach 2: Using the carriers directly through ` Setters ` and ` Getters ` ] ( #approach-2-using-the-carriers-directly-through-setters-and-getters )
25
+ * [ Common Behaviors] ( #common-behaviors )
22
26
23
27
<!-- tocstop -->
24
28
@@ -129,6 +133,9 @@ When spawning child processes:
129
133
- When spawning multiple child processes with different contexts or baggage,
130
134
each child SHOULD receive its own copy of the environment variables with
131
135
appropriate information.
136
+ - The onus is on the application owner for receiving the set context from the
137
+ SDK and passing it to its own process spawning mechanism. The language
138
+ implementations MUST NOT handle spawning processes.
132
139
133
140
#### Security
134
141
@@ -149,3 +156,52 @@ Windows.
149
156
- For maximum compatibility, implementations MUST:
150
157
- Use uppercase names consistently (` TRACEPARENT ` not ` TraceParent ` ).
151
158
- Use the canonical case when setting environment variables.
159
+
160
+ ## Supplementary Guidelines
161
+
162
+ > ** IMPORTANT** : This section is non-normative and provides implementation
163
+ > guidance only. It does not add requirements to the specification.
164
+
165
+ Language implementations of OpenTelemetry have flexibility in how they implement
166
+ environment variable context propagation. Two main approaches have been
167
+ identified as viable.
168
+
169
+ ### Approach 1: Providing a dedicated ` EnvironmentContextPropagator `
170
+
171
+ SDKs can create a dedicated propagator for environment variables. For example,
172
+ the [ OTel Swift] [ swift ] implements a custom ` EnvironmentContextPropagator ` that
173
+ handles the environment-specific logic internally, in essence decorating the
174
+ ` TextMapPropagator ` .
175
+
176
+ ### Approach 2: Using the carriers directly through ` Setters ` and ` Getters `
177
+
178
+ Language implementations can use the existing ` TextMapPropagator ` interface directly with
179
+ environment-specific carriers. Go and Python SDKs follow this pattern by
180
+ providing:
181
+
182
+ - ` EnvironmentGetter ` - creates an in-memory copy of the current environment
183
+ variables and reads context from that copy.
184
+ - ` EnvironmentSetter ` - writes context to a dictionary/map and provides the
185
+ dictionary/map to the application owner for them to use when spawning processes.
186
+
187
+ Examples:
188
+
189
+ - [ OpenTelemetry Prototype Go Implementation] [ gi ]
190
+ - [ OpenTelemetry Prototype Python Implementation] [ pi ]
191
+
192
+ [ gi ] : https://github.com/open-telemetry/opentelemetry-go/pull/6778
193
+ [ pi ] : https://github.com/open-telemetry/opentelemetry-python/pull/4609
194
+
195
+ ### Common Behaviors
196
+
197
+ Both approaches achieve the same outcome while offering different developer
198
+ experiences. Language implementations may choose either approach based on their
199
+ language's idioms and ecosystem conventions. The behaviors in both approaches
200
+ are the same in that they:
201
+
202
+ 1 . ** Extract context** : Read from environment variables and delegate to the
203
+ configured ` TextMapPropagator ` (e.g. W3C, B3) for parsing
204
+ 2 . ** Inject context** : Return a dictionary/map of environment variables that
205
+ application owners can pass to their process spawning libraries
206
+
207
+ [ swift ] : https://github.com/open-telemetry/opentelemetry-swift/blob/main/Sources/OpenTelemetrySdk/Trace/Propagation/EnvironmentContextPropagator.swift
0 commit comments