feat(otel): capture OTEL_CONFIG_WHITELIST vars with SDK-sourced type/default#4005
Draft
bm1549 wants to merge 1 commit into
Draft
feat(otel): capture OTEL_CONFIG_WHITELIST vars with SDK-sourced type/default#4005bm1549 wants to merge 1 commit into
bm1549 wants to merge 1 commit into
Conversation
…default The supported-configurations.json generator only scraped OTEL env vars that the C extension reads via ZAI_STRL(), so SDK-owned configs such as OTEL_EXPORTER_OTLP_HEADERS were never published. Scrape the OTEL_CONFIG_WHITELIST array in src/DDTrace/OpenTelemetry/Configuration.php as an additional source (scoped to the array literal so unrelated OTEL_ mentions can't leak in) and add that file to the input manifest. These OTEL vars are resolved by the open-telemetry/sdk PHP package, not the extension, so publishing them all as string/"" was inaccurate. Source their type and default by reflecting the SDK's ValueTypes/Defaults interfaces from a pinned, dedicated composer context (tooling/otel-sdk, open-telemetry/sdk 1.14.0, committed lock for reproducibility). The generator installs that context on demand and reads only the constant-bearing interface files (not the Composer autoloader, whose bootstrap reads ambient OTEL_* env). SDK types map to schema types (integer->int, list->array, map->map, enum/mixed->string, float/ratio->decimal, bool->boolean); per-signal OTLP vars inherit their generic counterpart. Applied to all OTEL entries; implementation labels and real extension-config defaults (e.g. OTEL_EXPORTER_OTLP_METRICS_ENDPOINT) are preserved. Note: defaults are the SDK's values; DatadogResolver overrides some at runtime (e.g. metrics temporality -> delta). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
bm1549
commented
Jun 22, 2026
Comment on lines
+313
to
+324
| // Type and default for OTEL configs, read by reflection from the pinned | ||
| // open-telemetry/sdk package (ValueTypes/Defaults interfaces) rather than the | ||
| // extension, which only observes these vars. SDK enum/mixed map to the schema's | ||
| // "string", list -> "array", map -> "map", integer -> "int", float/ratio -> | ||
| // "decimal", bool -> "boolean"; per the schema every default is a string, and | ||
| // map defaults are "". Per-signal OTLP exporter vars (e.g. *_LOGS_*) absent from | ||
| // ValueTypes inherit their generic OTEL_EXPORTER_OTLP_* counterpart, matching | ||
| // how the SDK resolves them. Defaults are the SDK's values; DatadogResolver | ||
| // overrides some at runtime (e.g. metrics temporality -> "delta"). | ||
| // Require only the constant-bearing interface files, not the Composer autoloader: | ||
| // the SDK's autoload "files" run bootstrap code that reads ambient OTEL_* env, | ||
| // which must not influence (or break) metadata generation. VariableTypes first, |
Contributor
Author
There was a problem hiding this comment.
I considered two solutions here
- Keeping
string/""- discarded since this isn't what the underlying OTel SDK uses so it made the docs slightly incorrect - Doing a one-time update of all of the config types/defaults - discarded since this would cause drift over time which we may not be aware of
Ultimately, this weird logic is isolated to a shell script, so it felt like an acceptable "lesser evil" so to say
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
The
supported-configurations.jsongenerator only capturedOTEL_*env vars that the C extension reads viaZAI_STRL(), so SDK-owned configs likeOTEL_EXPORTER_OTLP_HEADERSwere never published. This PR fixes that and makes the published type/default for every OTEL config accurate.OTEL_CONFIG_WHITELISTarray insrc/DDTrace/OpenTelemetry/Configuration.phpas an additional source (scoped to the array literal so unrelatedOTEL_mentions elsewhere in the file can't leak in), and add that file to the generator's input manifest.ValueTypes/Defaultsinterfaces, rather than publishing everything asstring/"". These vars are resolved by the SDK, not the extension. The SDK is pinned in a dedicated, minimal composer context (tooling/otel-sdk,open-telemetry/sdk1.14.0, committed lock) so generation is reproducible; the generator installs it on demand and reads only the constant-bearing interface files, not the Composer autoloader (whose bootstrap reads ambientOTEL_*env).*_LOGS_*) inherit their generic counterpart, matching how the SDK resolves them. Real extension configs (e.g.OTEL_EXPORTER_OTLP_METRICS_ENDPOINT) keep their authoritative extension default.Defaults are the SDK's values; note that
DatadogResolveroverrides some at runtime (e.g. metrics temporality →delta).The
Configuration ConsistencyCI job (which regenerates from the pinned SDK and fails on drift) passes. Thevalidate_supported_configurations_v2_local_filejob will be red until the matching versions are added to the Feature Parity configuration registry, which is handled separately.Reviewer checklist
🤖 Generated with Claude Code