fix(remote-config): support restored Node.js capability bits

[mtoffl01]

Motivation

DataDog/dd-trace-js#10573 restores the legacy per-setting APM_TRACING_* capability bits alongside SDK_CONFIGURATION. Node.js v6.17.0 through v6.19.0 advertise only SDK_CONFIGURATION, while v6.20.0 and later advertise both families but continue to consume only sdk_config.

System-tests previously treated the presence of any legacy bit as proof that a tracer consumed lib_config. This caused the dynamic-configuration parametric suite and debugger in-product enablement tests to send the wrong payload shape.

Changes

• Treat the presence of SDK_CONFIGURATION as authoritative for Node.js after APM_TRACING registration, including when legacy capability bits are also present.
• Preserve the existing libdatadog bit-collision safeguard for other tracers.
• Use SDK_CONFIGURATION to select sdk_config for Node.js 6.17.0 and later. Preserve the historical capability masks: 6.17.0–6.19.x advertise only SDK_CONFIGURATION, while 6.20.0+ also advertise the restored per-setting bits.
• Require SDK_CONFIGURATION plus the restored legacy bits on the 6.x release line from v6.20.0. Allow 7.0.0 prerelease main builds to advertise those extra bits without requiring them before dd-trace-js#10573 lands.
• Add regression coverage for the mixed Node.js capability set and the equivalent PHP interpretation.

Validation

Tested locally against the exact system_tests_binaries artifact produced by dd-trace-js#10573, reporting nodejs@7.0.0-pre.

[github-actions]

CODEOWNERS have been resolved as:

tests/parametric/capabilities.yml                                       @DataDog/system-tests-reviewers
tests/parametric/test_dynamic_configuration.py                          @DataDog/system-tests-reviewers
tests/test_the_test/test_remote_config.py                               @DataDog/system-tests-reviewers
utils/_remote_config.py                                                 @DataDog/system-tests-core

[datadog-prod-us1-5]

 

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 2 Pipeline jobs failed

Testing the test | System Tests (php, dev) / End-to-end #1 / apache-mod-8.0 1

View more details · View in GitHub Actions

Testing the test | all-jobs-are-green

View more details · View in GitHub Actions

ℹ️ 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: 1b3e5c5 | Docs | View more details | Give us feedback!}

[BridgeAR]

I do not think this is the right direction. Instead of handling it in the tracer, it should just be handled at the backend side where we receive the capabilities. That should mimic the existence of the older ones and we can keep everything as is.

[mtoffl01]

@BridgeAR , responded on slack, summarizing here:

Backend changes are not the right approach for the following reasons:

1. Testing in staging was difficult. I hit repeated environment and process issues (not problems with the code). Given points 2 and 3, it wasn't worth pushing through.
2. The backend would have to keep up with sdk_config by hand. Every new capability added to sdk_config (say, DBM) would need changes in the SDKs and the backend. That doesn't scale as the config list grows.
3. It assumes sdk_config means the same thing across tracer libraries and versions, but it doesn't. If dd-trace-js adds DBM to sdk_config in its next release and the backend starts reporting "DBM supported" whenever it sees sdk_config, that's wrong for every older dd-trace-js version where sdk_config only covered APM_TRACING_* and profiling. The same thing happens across every tracer library as their sdk_config support drifts apart.

The plan is to restore the capability bits in dd-trace-js now, then move to FPD soon, before sdk_config's config list changes any further.