You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(config): route env reads through the config singleton (#8241)
* refactor(config): route env reads through the config singleton
Replace `getValueFromEnvSources(...)` with config singleton reads across CI
visibility, runtime metrics, Azure metadata, AWS SDK, the git-cache helper,
and a few smaller helpers. The singleton already applies parsers, alias
precedence, and origin tracking; the helper bypasses all three and re-walks
the source order on every call.
A few sites need more than a drop-in replacement:
1. `serverless.js` lazily requires `./config` inside
`enableGCPPubSubPushSubscription` to break the
`config -> serverless -> config` import cycle.
2. `aws-sdk/base.js` needs to check `config.getOrigin(key) === 'default'`.
As a side effect, programmatic `batchPropagationEnabled` now wins over
env vars in every permutation; master's `??` chain happened to let the
service-specific env var beat a top-level programmatic value, which was
the one rung that disagreed with how every other plugin option resolves.
3. `git-cache.js` defers the env read into an idempotent `ensureCacheDir()`
first called from `cachedExec()`. The integration test also invalidates
`packages/dd-trace/src/config` from the require cache so the next
`require(...)` rebuilds the singleton from the just-set env vars.
4. `getJobIDFromDiagFile` reads `RUNNER_TEMP`, which is not a DD env var,
so it goes through `getEnvironmentVariable` rather than the singleton.
Unit tests use a proxyquire-injected
`() => proxyquire.noPreserveCache()(.../config, {})()` so per-test
`process.env` mutations still drive a fresh singleton.
`runtime_metrics.spec.js`'s synthetic config object gains
`DD_RUNTIME_METRICS_FLUSH_INTERVAL`. The aws-sdk plugin spec hoists
`process.env.DD_TRACE_AWS_SDK_*_BATCH_PROPAGATION_ENABLED` into the outer
`describe('Plugin')` so the env vars are set before the singleton is first
built. A new `serverless.spec.js` covers the cycle-broken branch directly.
Two call sites stay on the helper:
1. `llmobs/sdk.js`'s `enable()` reads `DD_LLMOBS_ENABLED` at call time so
user code (and the existing test) can mutate the env var after
`tracer.init()` and have it honored. The singleton snapshot can't
reflect a post-init mutation.
2. `test-optimization-cache.js`'s `setupSettingsCachePath` writes
`process.env` so NYC subprocesses inherit the path; the singleton is a
one-shot snapshot of the parent's env.
Drive-by fix:
* The `DD_TRACE_AWS_SDK_*_BATCH_PROPAGATION_ENABLED` entries in
`supported-configurations.json` flip from `default: "true"` /
`implementation: "A"` to `default: "false"` / `implementation: "B"`. The
shipped chain has always defaulted to `false` via `isTrue(undefined)`.
* fix(serverless): keep Pub/Sub push check on the env helper
`enableGCPPubSubPushSubscription` lazy-required `./config` to break the
`config -> serverless -> config` import cycle. `HttpPlugin.plugins` calls
it on every `tracer.use('http')`, and each `proxyquire.noPreserveCache(
.../config)` in the test harness clears `config/index.js` from
`require.cache`. The next call then re-evaluates the module and builds a
fresh `Config()` (parsing `supported-configurations.json`, walking
`process.env`, reading git files). AppSec / express CI timed out three
RASP-SSRF `before all` hooks at 5 s.
Read `DD_TRACE_GCP_PUBSUB_PUSH_ENABLED` via `getValueFromEnvSources` and
inline it so `K_SERVICE !== undefined` short-circuits the env lookup.
Drive-by fix:
* `.github/CODEOWNERS`: route the new `test/serverless.spec.js` to
`@DataDog/apm-serverless`, matching `azure_metadata.spec.js` so
`lint:codeowners:ci` stops failing on it.
0 commit comments