chore(tests): add LMI e2e suite and run-scoped shared capacity provider#5465
Open
svozza wants to merge 9 commits into
Open
chore(tests): add LMI e2e suite and run-scoped shared capacity provider#5465svozza wants to merge 9 commits into
svozza wants to merge 9 commits into
Conversation
… Managed Instances Adds an opt-in (RUN_LMI_TESTS) e2e suite that provisions an ephemeral Lambda Managed Instances capacity provider (dual-stack IPv6 VPC, no NAT, CloudWatch Logs interface endpoint) and proves the InvokeStore-backed log attribute isolation across invocations multiplexed into the same execution environment via a module-scoped promise barrier. Testing utils changes: - TestLmiCapacityProvider construct + ./resources/capacity-provider export - ExtraTestProps.lmi option on TestNodejsFunction (memorySize>=2048 floor, $LATEST.PUBLISHED qualified output) - includeTailLogs opt-out on invoke helpers (Tail unsupported on LMI) Related to #5092, findings posted on the issue.
… CloudWatch polling The handler tees process.stdout.write (the Logger's production write path) and returns its own log lines in the response payload, making log collection deterministic — no FilterLogEvents polling, no ingestion latency, no CloudWatch client in the test. Captured lines are filtered by the InvokeStore-scoped invocationKey rather than function_request_id: addContext stores the Lambda context in instance state, so under LMI multiplexing the request id stamped on log lines can belong to a different invocation. Tracked separately as a bug (see lmi-request-id-bug-handoff.md); once fixed, the filter should flip back to function_request_id as a regression check.
…ogs by request id With the lambda context now scoped per invocation under LMI (#5430), the handler selects its own log lines by function_request_id — an independent per-invocation attribute — and the test asserts the InvokeStore-scoped invocationKey on those lines, making the suite a regression check for both the context scoping and appendKeys isolation. The suite adds ~4 minutes to the logger e2e cell, inside the agreed budget for running on every e2e dispatch, so the RUN_LMI_TESTS gate and workflow input are removed.
The e2e suites are I/O-bound (waiting on CloudFormation), but vitest sizes its worker pool from CPU cores, so on 2-core CI runners only 3 of the 6 logger e2e files ran concurrently and the rest queued — each then paying its own stack deploy after waiting. With 8 workers all suites deploy their stacks up front and the cell duration approaches the slowest single suite (~6 min measured) instead of a serialized ~8 min. CloudFormation read-API pressure from the extra concurrent stack monitors is bounded by the existing DescribeStackEvents polling patch in the testing package (10s interval per stack).
With all 36 matrix cells sharing one account, the extra concurrent stack operations from 8-worker logger cells pushed the account-wide CloudFormation API rate over the edge: three unrelated cells failed with 'Throttling: Rate exceeded' on stack deploys. Back to default worker sizing; cell-duration work moves to the run-scoped shared capacity provider follow-up, which removes per-cell VPC/CP stacks entirely instead of racing them.
Instead of every LMI suite provisioning its own capacity provider + VPC, a workflow run can deploy one shared capacity provider per architecture up front and pass its ARN to each suite via LMI_CAPACITY_PROVIDER_ARN. - add packages/testing/src/lmi/cli.ts with deploy/destroy commands that manage a run-scoped LmiShared-<runId>-<arch> stack and print the capacity provider ARN on stdout - TestNodejsFunction accepts a capacity provider ARN string and attaches the function via L1 CfnFunction.capacityProviderConfig (an imported capacity provider has no addFunction) - ExtraTestProps.lmi.capacityProvider widened to CapacityProvider | string - TestLmiCapacityProvider ctor loosened to Pick<TestStack, 'stack'> so the CLI can build the stack standalone - logger lmi.test.ts reads LMI_CAPACITY_PROVIDER_ARN, falling back to an ephemeral per-suite capacity provider when unset
powertools-for-aws-oss-automation
Bot
added
the
size/XL
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
The --run-id argument flows into a CloudFormation stack name and, via join(tmpdir(), ...), into the assembly output path that is later read back. A crafted value (e.g. containing ../) could escape tmpdir(), so restrict it to the alphanumerics-and-hyphens set CloudFormation already requires for stack names and reject anything else at the boundary.
powertools-for-aws-oss-automation
Bot
added
size/XL
The path-injection scanner's taint analysis doesn't recognise the run-id regex guard as sanitisation, and its guidance is to validate the constructed path before touching the file system. Resolve the assembly output directory and assert it stays within os.tmpdir() before it is written to or read back, keeping the run-id validation as the input-side guard for defence in depth.
powertools-for-aws-oss-automation
Bot
added
size/XL
The constructor's cognitive complexity hit 17 (limit 15) once it carried the nested ARN-vs-construct capacity-provider branching. Move that logic into two private methods so the constructor keeps a flat structure and the two attachment strategies read independently. No behaviour change.
powertools-for-aws-oss-automation
Bot
added
size/XL
|
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
2 participants
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.
Summary
Adds an end-to-end test that validates Logger's
InvokeStore-backed log-attribute isolation on Lambda Managed Instances (LMI), where multiple invocations run concurrently in the same execution environment. Also introduces the testing infrastructure to support it, including a run-scoped shared capacity provider so LMI suites don't each provision their own VPC + capacity provider.Changes
packages/logger/tests/e2e/lmi.test.ts) that saturates a deliberately small fleet, forces concurrent invocations to multiplex into shared execution environments, and asserts each invocation's appended keys stay isolatedprocess.stdout.write(the production write path) and returning them in the response payload, making log collection deterministic — no CloudWatch polling or ingestion latencyInvokeStore-scopedinvocationKey, and additionally assert onfunction_request_idas a regression check now that the Lambda context is scoped per invocation under LMI (fix(logger): scope lambda context per invocation under LMI concurrency #5430)TestLmiCapacityProvider(dual-stack IPv6-only VPC, egress-only IGW, CloudWatch Logs interface endpoint — no NAT) and extendTestNodejsFunctionto attach a function to a capacity provider by construct or by ARNpackages/testing/src/lmi/cli.tswith deploy/destroy commands that manage a run-scopedLmiShared-<runId>-<arch>stack and print the capacity provider ARN, so a workflow run can provision one shared capacity provider per architecture up front and pass it to each suite viaLMI_CAPACITY_PROVIDER_ARN(suites fall back to an ephemeral per-suite provider when unset)RUN_LMI_TESTSgate and workflow input)Issue number: closes #5092
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.