oss_24_declarative_config_present_null_defaults

[ocelotl]

Closes #31

Declarative config: a present-but-null component (e.g. console: with no value) now builds that component with defaults instead of raising ConfigurationError; present-null is carried through conversion distinctly from an absent key (Linear OSS-24, finding L1).

Validation: scope contained to opentelemetry-configuration + changelog; full package suite 369 passed.

Linear issue: https://linear.app/dash0/issue/OSS-24/l1-declarative-config-present-but-null-components-fail-instead-of

[ocelotl]

🔒 Internal (dash0) — not for upstream.

• Linear: https://linear.app/dash0/issue/OSS-24/l1-declarative-config-present-but-null-components-fail-instead-of (finding L1)
• Closes: oss_24_declarative_config_present_null_defaults #31 · Branch: oss_24_declarative_config_present_null_defaults · Commit: 9e7d6534b
• Validation: opentelemetry-configuration suite 369 passed; scope package + changelog.

[ocelotl]

📣 Public-facing draft — to be used for the upstream PR in open-telemetry/opentelemetry-python. No internal references; copy verbatim.

Title: Fix declarative config present-but-null components to build with defaults

What

Make a present-but-null component value in declarative configuration build that component with defaults, instead of raising ConfigurationError.

Why

A present-but-null value (e.g. console: with no value) mapped to None during dict-to-dataclass conversion, indistinguishable from an absent key. Component factories select with value is not None, so a present-null component was treated as "not configured" and raised ConfigurationError.

Spec

configuration/sdk.md requires parsing to distinguish a missing key from a present-null one, and a present-null component MUST be created with all defaults (matching Java and Go, which bind the raw node and construct with defaults).

How

_convert_value is only invoked for keys actually present in the parsed mapping — absent keys fall through to dataclass field defaults — so a None value there always means present-null. It is now carried through as:

• a defaults-only dataclass instance for dataclass-typed fields (e.g. otlp_http: → OtlpHttpExporter() with all fields None, so the exporter reads its own defaults / env vars),
• an empty mapping for mapping-alias fields (e.g. the console exporter, typed dict[str, Any] | None), so the selecting factory still fires,
• None for primitives.
  Absent keys remain None, preserving "not configured" semantics. No factory-selection changes needed.

Tests

New unit tests in test_conversion.py (present-null dataclass → defaults instance; present-null mapping-alias console → {}; present-null primitive → None; absent → None; populated still converts) and factory-level tests in test_tracer_provider.py (present-null console builds a ConsoleSpanExporter; absent exporter type still raises). Full package suite: 369 passed.

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.

[ocelotl]

Closing as superseded by upstream. This PR addressed OSS-24 / L1 (declarative-config present-but-null components should build with defaults instead of raising). Upstream open-telemetry#5454 ("treat present-null config value as empty mapping", commit 4ea521a73) has since implemented exactly this in _conversion.py::_convert_value (coerces present-null to {} for dict-typed nodes and empty-constructible dataclasses, with the required-field guard). This branch's remaining diff is tests + changelog only — the production behavior is already upstream. No longer needed.