fix: apply Datadog env vars via synth-time CDK aspect#622
Draft
ava-silver wants to merge 4 commits into
Draft
Conversation
This comment has been minimized.
This comment has been minimized.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

What does this PR do?
Applies Datadog Lambda environment variables from a synth-time CDK Aspect instead of eagerly during
addLambdaFunctions. This removes all reads of aws-cdk-lib's privateFunction.environmentfield and preserves the original "don't override user-set env vars" behavior -- for vars set both before and afteraddLambdaFunctions.Motivation
aws-cdk-lib changed
Function.environment's internal shape in a semver-minor (2.252 -> 2.253), breakingcdk synth(#596). The root cause is that the library reads that private field to avoid clobbering user-set env vars, and aws-cdk-lib exposes no public API to read env vars eagerly.#621 fixes the crash with a
WeakMapthat tracks the library's own writes, but it cannot see env vars a user sets viafunc.addEnvironment()beforeaddLambdaFunctions()-- a documented behavior change. This PR explores keeping that behavior.How it works
A CDK Aspect runs during synthesis, after all user
addEnvironmentcalls have executed (regardless of ordering). At that point the function's env vars can be read through the public token-resolution API --Stack.of(fn).resolve(cfnFunction.environment)-- which returns the fully-resolved{ Variables: {...} }. The aspect fills in Datadog defaults only for keys the user hasn't set, then appends source code integration tags toDD_TAGS.Changes
src/env-aspect.ts(new) --DatadogLambdaEnvAspectimplementingIAspect. Reads resolved env, applies defaults, appends SCI tags. Git overrides are read lazily via getter closures sooverrideGitMetadataworks regardless of call order.src/env.tsreadResolvedFunctionEnv(fn)-- public-API read helper (Stack.resolve).getSourceCodeIntegrationTags(...)/applySourceCodeIntegration(...)-- git tag computation split out, reads existingDD_TAGSfrom the passed-in resolved env map.applyEnvVariables(fn, baseProps, existingEnv)-- now takes the resolved env map instead of reading the private field.src/datadog-lambda.tsaddLambdaFunctionsregisters the aspect (once per stack) and adds functions to its target set instead of applying env vars eagerly. Prop-driven unconditional writes stay eager.overrideGitMetadatajust records overrides -- the aspect buildsDD_TAGSfresh at synth, so no rewriting of already-added functions (and no private field access).addGitCommitMetadataregisters the given functions with the aspect.Behavior vs #621
Function.environmentDatadogLambdaPropsconfigaddEnvironmentafteraddLambdaFunctionsaddEnvironmentbeforeaddLambdaFunctionsThe entire existing test suite passes without changing the env-var assertions -- including the "does not override user-defined env variables before/after" tests that #621 had to rewrite. Only the
overrideGitMetadatatests changed, to assert againstTemplate.fromStack()instead of reading the private field directly.Tradeoffs / open questions
addLambdaFunctions.datadogAppSecMode: tracerruntime check inapplyEnvVariablesnow throws at synth rather than ataddLambdaFunctions.resolve()on tokenized values. Env values that are CDK tokens resolve to${Token[...]}strings; presence checks are unaffected, but appending to a tokenizedDD_TAGSwould be odd (edge case, same as before).Testing Guidelines
yarn test-- full suite passes (240 tests). Manualcdk synthon an example stack recommended before considering for real.Types of Changes