fix(logger): scope log buffer per invocation under LMI concurrency - #5543
Open
vishwakt wants to merge 1 commit into
Open
fix(logger): scope log buffer per invocation under LMI concurrency#5543vishwakt wants to merge 1 commit into
vishwakt wants to merge 1 commit into
Conversation
The log buffer cleared all entries whenever a log was buffered for a trace id it had not seen before, based on the assumption that only one request can be in flight per execution environment. Under Lambda Managed Instances concurrency that assumption no longer holds: an invocation starting to buffer wiped every other in-flight invocation's buffered logs, so a failing invocation had nothing left to flush. Scope the buffer through the InvokeStore when concurrency is enabled, so each invocation's buffered logs live and die with its invocation context. The sequential path keeps the existing instance buffer and its new-trace cleanup behavior, preserving the stale-buffer safeguard from aws-powertools#3705. Closes aws-powertools#5541
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
1 participant
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
Changes
The log buffer cleared all entries whenever a log was buffered for a trace id it had not seen before, based on the assumption that only one request can be in flight per execution environment (the comment in
bufferLogItem()stated this explicitly). Under Lambda Managed Instances concurrency that assumption no longer holds: an invocation starting to buffer wiped every other in-flight invocation's buffered logs, so a failing invocation had nothing left to flush and its debug context was silently lost.Following the direction agreed in the issue, the buffer is now scoped through the InvokeStore when concurrency is enabled (
AWS_LAMBDA_MAX_CONCURRENCYset): a new private#getBuffer()accessor returns an invocation-scopedCircularMapstored in the InvokeStore, so each invocation's buffered logs live and die with its invocation context and no cross-invocation cleanup is needed. The sequential path is unchanged: it keeps the instance-level buffer and its new-traceclear()behavior, preserving the stale-buffer safeguard introduced in #3705.bufferLogItem(),flushBuffer(), andclearBuffer()all resolve the buffer through the accessor. Theclear()now only runs on the sequential path.Added regression tests in
tests/unit/concurrency/logBuffer.test.ts:clearBuffer()throws when concurrency is enabled but the InvokeStore is unavailable, matching the behavior of the attribute storeAll existing logger unit tests pass unchanged (226 tests), confirming sequential behavior is preserved, with 100% coverage on
Logger.ts.Issue number: closes #5541
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.