Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.85%. Comparing base (b87fa99) to head (a9bdc8b).

@@             Coverage Diff              @@
##               main    #8356      +/-   ##
============================================
+ Coverage     90.82%   90.85%   +0.03%     
- Complexity     7927     7936       +9     
============================================
  Files           895      895              
  Lines         23872    23872              
  Branches       2378     2378              
============================================
+ Hits          21681    21690       +9     
  Misses         1446     1446              
+ Partials        745      736       -9     

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

This issue also impacts the rule-based sampler and resource attribute detectors, as they both get empty collections where a null value would be expected if the attribute is not present in the yaml.

While on the java-side, having an null collection feels odd and requires more code on the consumer side, doing that allows to closely match the yaml semantics where we need to know if something is present or not, so this seems to be a good compromise. The downside however is that we have to test more combinations.

For example, from the resource detector in kitchen sink example: https://github.com/open-telemetry/opentelemetry-configuration/blob/main/snippets/Resource_kitchen_sink.yaml

resource:
  # SNIPPET_START
  attributes:
  detection/development:
    attributes:
      included:
        - process.*
      excluded:
        - process.command_args
    detectors:
      - process:

Here removing one of included and excluded would trigger an exception thanks to the checks added in #8266

Same with rule-based sampler, the following configuration currently fails if we remove any of the included or excluded attribute is removed:

tracer_provider:
  processors:
    - simple:
        exporter:
          console:
  sampler:
    composite/development:
      rule_based:
        rules:
          - attribute_patterns:
              key: http.path
              included:
                - /internal/*
              excluded:
                - /internal/special/*

Is there any concern about existing code assuming non-null because of prior behavior?

I did an analysis of all the cases where declarative config has arrays and all the interpretation logic has null checks already, so this shouldn't be a problem