[avangelillo]

What does this PR do?

Stops the plugin from overriding a user-set DD_LOGS_INJECTION when addExtension: true.

DD_LOGS_INJECTION now resolves per function, first match wins:

1. A function-level DD_LOGS_INJECTION.
2. An explicitly set custom.datadog.injectLogContext.
3. A provider-level DD_LOGS_INJECTION, copied into the function's environment (the same pattern addDDEnvVars uses for DD_SERVICE, DD_ENV, etc.).
4. The default: true, or false when the extension is used. That second case keeps the current default.

A null value (an empty YAML key) counts as unset at every level.

To tell an explicit injectLogContext apart from the default, injectLogContext is removed from defaultConfiguration and is now optional in Configuration. setEnvConfiguration takes an optional providerEnvironment, and index.ts passes provider.environment into it.

Motivation

Fixes #747 (SVLS-9919). Since #396, DD_LOGS_INJECTION=false was forced whenever the extension was enabled. Function-level env, provider-level env and injectLogContext: true all had no effect. Users with JSON loggers such as pino couldn't get dd.trace_id / dd.span_id in their logs without workarounds.

Background: why #396 forced false, and why this undoes it

#396 (SLS-2166, June 2023) aimed to "deprecate DD_LOGS_INJECTION when using the Extension", because the extension correlates logs and traces by Lambda request ID. Follow-up PRs #401 here and DataDog/datadog-cdk-constructs#191 called it an "unneeded env var" and tried to stop adding it at all, to save env var space. Both were closed without merging. Nothing in that work argues for blocking users who set the variable themselves.

CDK parity: datadog-cdk-constructs made the same change in DataDog/datadog-cdk-constructs#188 with setEnvIfUnset(DD_LOGS_INJECTION, "false"), which defaults to false with the extension but keeps a value the user already set. That's still how it works today. Only this plugin overwrote the user's value unconditionally. This PR brings the plugin in line with the CDK constructs: still false by default with the extension, but a user-set value is respected.

Testing Guidelines

• Updated the existing getConfig / setEnvConfiguration specs that asserted the old default.
• Added specs for each step of the order above: an explicit injectLogContext: true with the extension, a function-level value, function-level beating injectLogContext, injectLogContext beating a provider-level value in both directions (with and without the extension), a provider-level value replacing the extension default, null counting as unset, a null provider environment, and the default without the extension.
• Added plugin-level tests (index.spec.ts) for a null provider.environment (an empty environment: key in YAML), a provider-level value, and injectLogContext: true with the extension.
• yarn test (vitest, 268 passing), yarn build, yarn lint (oxlint) and yarn check-formatting (oxfmt) are clean. ./scripts/run_snapshot_tests.sh with Serverless 3.39 (same as CI) passes for all three snapshots without regenerating them. The default output is unchanged.

Additional Notes

Upgrade note: with the extension, the plugin used to force DD_LOGS_INJECTION=false no matter what was configured. After upgrading, these services start getting DD_LOGS_INJECTION=true:

• services with injectLogContext: true in their config (it was the plugin's default value until now),
• functions with a leftover DD_LOGS_INJECTION: true in their environment,
• services with DD_LOGS_INJECTION: true in provider.environment.

Their log output may change, because the tracer will start adding dd.trace_id / dd.span_id. To keep the old behavior, remove those settings or set them to false. This should go in the release notes.

Also adds an injectLogContext row to the README configuration table. setEnvConfiguration treats a null provider.environment (an empty environment: key in YAML) as empty. This PR never assigns to provider.environment: without the extension nothing else creates it, and an empty one would add an Environment block to excluded functions. With the extension, addDDEnvVars already creates it, as before.

Behavior change without the extension: a provider-level DD_LOGS_INJECTION used to be overridden at function level by the default injectLogContext: true. It's now applied, unless injectLogContext is set explicitly. An explicit injectLogContext still beats it, the same as before.

Types of changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog

🤖 Generated with Claude Code

[datadog-prod-us1-3]

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