fix(parametric): normalize OTel boolean attribute assertions

[AlexeyKuznetsov-DD]

Motivation

The same OTel boolean attribute can have different representations depending on the tracer and trace protocol:

1. system-tests previously required "true" and "false" specifically from span["meta"]. That assertion describes the legacy representation rather than the semantic OTel value, so it fails when a valid boolean arrives through span["metrics"] as 1 or 0.

2. dd-trace-java keeps OTel booleans as Java Boolean tags. With trace protocol v0.4, those values are serialized as "true"/"false" metadata. With v1.0, TraceMapperV1 writes them as typed boolean attributes, including flattened boolean-array elements.

3. dd-trace-py further demonstrates why the assertion should not depend on one storage map. Scalar OTel booleans can follow the numeric attribute path and become 1/0 metrics, while flattened boolean-array values can follow the tag path and remain string metadata.

4. dd-apm-test-agent exposes all received traces through the legacy v0.4-shaped meta/metrics model. When decoding a v1.0 typed boolean, it performs the conversion to numeric 1 or 0; because those are numbers, they are placed in metrics. The Java tracer itself does not convert its v1.0 boolean attributes into numeric metrics.

As a result, "true", True, and 1 represent the same boolean value for this cross-library behavioral test, as do "false", False, and 0.

Changes

Updates the parametric OTel attribute test to compare boolean values semantically instead of requiring them to be lowercase strings in span["meta"].

The test now:

• Builds a combined attribute view from span["meta"] and span["metrics"] for boolean assertions.
• Uses is_same_boolean(...) for scalar and flattened-array boolean attributes.
• Extends is_same_boolean(...) to recognize numeric 1 and 0 in addition to native and string booleans.
• Keeps all non-boolean assertions strict and in their existing meta or metrics maps.

Workflow

1. ⚠️ Create your PR as draft ⚠️
2. Work on you PR until the CI passes
3. Mark it as ready for review
   • Test logic is modified? -> Get a review from RFC owner.
   • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed and the CI green, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

• Anything but tests/ or manifests/ is modified ? I have the approval from R&P team
• A docker base image is modified?
  • the relevant build-XXX-image label is present
• A scenario is added, removed or renamed?
  • Get a review from R&P team

[github-actions]

CODEOWNERS have been resolved as:

tests/parametric/test_otel_span_methods.py                              @DataDog/system-tests-core @DataDog/apm-sdk-capabilities
utils/dd_types/_utils.py                                                @DataDog/system-tests-core

[datadog-datadog-prod-us1-2]

 

⚠️ Warnings

🚦 1 Pipeline job failed

Testing the test | all-jobs-are-green     

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 552a3d2 | Docs | Datadog PR Page | Give us feedback!}