fix(lambda): bump the aws-powertools group in /lambdas with 4 updates

[dependabot]

Bumps the aws-powertools group in /lambdas with 4 updates: @aws-lambda-powertools/parameters, @aws-lambda-powertools/logger, @aws-lambda-powertools/metrics and @aws-lambda-powertools/tracer.

Updates @aws-lambda-powertools/parameters from 2.15.0 to 2.16.0

Release notes

Sourced from @​aws-lambda-powertools/parameters's releases.

v2.16.0

Summary

We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush them automatically on error or manually as needed.

We also fixed a bug in the Batch Processing utility that prevented SQS FIFO messages from the same group to be processed correctly during retries

Finally, we now publish our Lambda layers to three new regions Mexico (mx-central-1), Thailand (ap-southeast-7), and Malaysia (ap-southeast-5).

⭐️ Thanks to @​VatsalGoel3 and @​ConnorKirk for their significant contributions to this release!

New Log Buffering feature

Docs

You can now enable log buffering by passing logBufferOptions when initializing a new Logger instance. This feature allows you to:

• Buffer logs at the WARN, INFO, DEBUG, and TRACE levels
• Automatically flush logs on error or manually as needed
• Reduce CloudWatch costs by decreasing the number of emitted log messages

Configuration options

Option	Description	Default
maxBytes	Maximum size of the buffer in bytes	20480
minLevel	Minimum log level to buffer (more verbose levels are also buffered)	DEBUG
flushOnErrorLog	Whether to flush buffer when an error is logged	true
enabled	Whether log buffering is enabled	N/A

When log buffering is enabled, you can now pass a new opt-in flushBufferOnUncaughtError flag to the injectLambdaContext() class method decorator and Middy.js middleware. When enabled, 1/ we'll intercept any error thrown, 2/ flush the buffer, and 3/ re-throw your original error. This enables you to have detailed logs from your application when you need them the most.

For detailed explanations with diagrams, please refer to our comprehensive documentation.

Buffering FAQs

Q: Does the buffer persist across Lambda invocations? A: No. Each Lambda invocation has its own buffer. The buffer initializes when the Lambda function is invoked and clears after function completion or manual flushing.

Q: Are my logs buffered during cold starts? A: No. We never buffer logs during cold starts to ensure all logs from this phase are immediately available for debugging.

Q: How can I prevent log buffering from consuming excessive memory? A: You can limit the size of the buffer by setting the maxBytes option in the logBufferOptions constructor parameter. This will ensure that the buffer does not grow indefinitely and consume excessive memory.

Q: What happens if the log buffer reaches its maximum size?

... (truncated)

Changelog

Sourced from @​aws-lambda-powertools/parameters's changelog.

2.16.0 (2025-03-07)

Bug Fixes

• batch: clear message group references after request (#3674) (270115e)
• ci: Update layer balance scripts (#3660) (aa14637)
• parser: envelope sub-path exports regression (#3667) (beac102)
• parser: update S3 Event Schema (#3671) (c14c7b3)

Features

• logger: Enable log buffering feature (#3641) (8203016)
• logger: flush buffer on uncaught error decorator (#3676) (28db2e3)
• logger: Flush buffer on uncaught error in Middy middleware (#3690) (23eebe4)
• logger: refresh sample rate calculation before each invocation (#3672) (8c8d6b2)
• validation: add @​validator decorator for JSON Schema validation (#3679) (ae6b7cf)
• validation: Add Middy.js middleware for JSON Schema validation (#3694) (443202b)
• validation: implement validate function (#3662) (f55127b)

Commits

• 540a14b chore(ci): bump version to 2.16.0 (#3702)
• 1ca4b26 refactor(logger): align implementation to spec + docs (#3701)
• 1a48d2c chore(deps): bump jinja2 from 3.1.5 to 3.1.6 in /docs (#3698)
• 443202b feat(validation): Add Middy.js middleware for JSON Schema validation (#3694)
• 34d917e chore(deps): bump @​types/node from 22.13.8 to 22.13.9 (#3695)
• 23eebe4 feat(logger): Flush buffer on uncaught error in Middy middleware (#3690)
• 58f376e chore(deps): bump the aws-cdk group across 1 directory with 2 updates (#3687)
• 9839e13 chore(deps): bump squidfunk/mkdocs-material from 2615302 to 047452c in /d...
• 0693f71 chore(deps): bump mkdocs-material from 9.6.5 to 9.6.7 in /docs (#3686)
• ae6b7cf feat(validation): add @​validator decorator for JSON Schema validation (#3679)
• Additional commits viewable in compare view

Updates @aws-lambda-powertools/logger from 2.15.0 to 2.16.0

Release notes

Sourced from @​aws-lambda-powertools/logger's releases.

v2.16.0

Summary

We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush them automatically on error or manually as needed.

We also fixed a bug in the Batch Processing utility that prevented SQS FIFO messages from the same group to be processed correctly during retries

Finally, we now publish our Lambda layers to three new regions Mexico (mx-central-1), Thailand (ap-southeast-7), and Malaysia (ap-southeast-5).

⭐️ Thanks to @​VatsalGoel3 and @​ConnorKirk for their significant contributions to this release!

New Log Buffering feature

Docs

You can now enable log buffering by passing logBufferOptions when initializing a new Logger instance. This feature allows you to:

• Buffer logs at the WARN, INFO, DEBUG, and TRACE levels
• Automatically flush logs on error or manually as needed
• Reduce CloudWatch costs by decreasing the number of emitted log messages

Configuration options

Option	Description	Default
maxBytes	Maximum size of the buffer in bytes	20480
minLevel	Minimum log level to buffer (more verbose levels are also buffered)	DEBUG
flushOnErrorLog	Whether to flush buffer when an error is logged	true
enabled	Whether log buffering is enabled	N/A

When log buffering is enabled, you can now pass a new opt-in flushBufferOnUncaughtError flag to the injectLambdaContext() class method decorator and Middy.js middleware. When enabled, 1/ we'll intercept any error thrown, 2/ flush the buffer, and 3/ re-throw your original error. This enables you to have detailed logs from your application when you need them the most.

For detailed explanations with diagrams, please refer to our comprehensive documentation.

Buffering FAQs

Q: Does the buffer persist across Lambda invocations? A: No. Each Lambda invocation has its own buffer. The buffer initializes when the Lambda function is invoked and clears after function completion or manual flushing.

Q: Are my logs buffered during cold starts? A: No. We never buffer logs during cold starts to ensure all logs from this phase are immediately available for debugging.

Q: How can I prevent log buffering from consuming excessive memory? A: You can limit the size of the buffer by setting the maxBytes option in the logBufferOptions constructor parameter. This will ensure that the buffer does not grow indefinitely and consume excessive memory.

Q: What happens if the log buffer reaches its maximum size?

... (truncated)

Changelog

Sourced from @​aws-lambda-powertools/logger's changelog.

2.16.0 (2025-03-07)

Bug Fixes

• batch: clear message group references after request (#3674) (270115e)
• ci: Update layer balance scripts (#3660) (aa14637)
• parser: envelope sub-path exports regression (#3667) (beac102)
• parser: update S3 Event Schema (#3671) (c14c7b3)

Features

• logger: Enable log buffering feature (#3641) (8203016)
• logger: flush buffer on uncaught error decorator (#3676) (28db2e3)
• logger: Flush buffer on uncaught error in Middy middleware (#3690) (23eebe4)
• logger: refresh sample rate calculation before each invocation (#3672) (8c8d6b2)
• validation: add @​validator decorator for JSON Schema validation (#3679) (ae6b7cf)
• validation: Add Middy.js middleware for JSON Schema validation (#3694) (443202b)
• validation: implement validate function (#3662) (f55127b)

Commits

• 540a14b chore(ci): bump version to 2.16.0 (#3702)
• 1ca4b26 refactor(logger): align implementation to spec + docs (#3701)
• 1a48d2c chore(deps): bump jinja2 from 3.1.5 to 3.1.6 in /docs (#3698)
• 443202b feat(validation): Add Middy.js middleware for JSON Schema validation (#3694)
• 34d917e chore(deps): bump @​types/node from 22.13.8 to 22.13.9 (#3695)
• 23eebe4 feat(logger): Flush buffer on uncaught error in Middy middleware (#3690)
• 58f376e chore(deps): bump the aws-cdk group across 1 directory with 2 updates (#3687)
• 9839e13 chore(deps): bump squidfunk/mkdocs-material from 2615302 to 047452c in /d...
• 0693f71 chore(deps): bump mkdocs-material from 9.6.5 to 9.6.7 in /docs (#3686)
• ae6b7cf feat(validation): add @​validator decorator for JSON Schema validation (#3679)
• Additional commits viewable in compare view

Updates @aws-lambda-powertools/metrics from 2.15.0 to 2.16.0

Release notes

Sourced from @​aws-lambda-powertools/metrics's releases.

v2.16.0

Summary

We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush them automatically on error or manually as needed.

We also fixed a bug in the Batch Processing utility that prevented SQS FIFO messages from the same group to be processed correctly during retries

Finally, we now publish our Lambda layers to three new regions Mexico (mx-central-1), Thailand (ap-southeast-7), and Malaysia (ap-southeast-5).

⭐️ Thanks to @​VatsalGoel3 and @​ConnorKirk for their significant contributions to this release!

New Log Buffering feature

Docs

You can now enable log buffering by passing logBufferOptions when initializing a new Logger instance. This feature allows you to:

• Buffer logs at the WARN, INFO, DEBUG, and TRACE levels
• Automatically flush logs on error or manually as needed
• Reduce CloudWatch costs by decreasing the number of emitted log messages

Configuration options

Option	Description	Default
maxBytes	Maximum size of the buffer in bytes	20480
minLevel	Minimum log level to buffer (more verbose levels are also buffered)	DEBUG
flushOnErrorLog	Whether to flush buffer when an error is logged	true
enabled	Whether log buffering is enabled	N/A

When log buffering is enabled, you can now pass a new opt-in flushBufferOnUncaughtError flag to the injectLambdaContext() class method decorator and Middy.js middleware. When enabled, 1/ we'll intercept any error thrown, 2/ flush the buffer, and 3/ re-throw your original error. This enables you to have detailed logs from your application when you need them the most.

For detailed explanations with diagrams, please refer to our comprehensive documentation.

Buffering FAQs

Q: Does the buffer persist across Lambda invocations? A: No. Each Lambda invocation has its own buffer. The buffer initializes when the Lambda function is invoked and clears after function completion or manual flushing.

Q: Are my logs buffered during cold starts? A: No. We never buffer logs during cold starts to ensure all logs from this phase are immediately available for debugging.

Q: How can I prevent log buffering from consuming excessive memory? A: You can limit the size of the buffer by setting the maxBytes option in the logBufferOptions constructor parameter. This will ensure that the buffer does not grow indefinitely and consume excessive memory.

Q: What happens if the log buffer reaches its maximum size?

... (truncated)

Changelog

Sourced from @​aws-lambda-powertools/metrics's changelog.

2.16.0 (2025-03-07)

Bug Fixes

• batch: clear message group references after request (#3674) (270115e)
• ci: Update layer balance scripts (#3660) (aa14637)
• parser: envelope sub-path exports regression (#3667) (beac102)
• parser: update S3 Event Schema (#3671) (c14c7b3)

Features

• logger: Enable log buffering feature (#3641) (8203016)
• logger: flush buffer on uncaught error decorator (#3676) (28db2e3)
• logger: Flush buffer on uncaught error in Middy middleware (#3690) (23eebe4)
• logger: refresh sample rate calculation before each invocation (#3672) (8c8d6b2)
• validation: add @​validator decorator for JSON Schema validation (#3679) (ae6b7cf)
• validation: Add Middy.js middleware for JSON Schema validation (#3694) (443202b)
• validation: implement validate function (#3662) (f55127b)

Commits

• 540a14b chore(ci): bump version to 2.16.0 (#3702)
• 1ca4b26 refactor(logger): align implementation to spec + docs (#3701)
• 1a48d2c chore(deps): bump jinja2 from 3.1.5 to 3.1.6 in /docs (#3698)
• 443202b feat(validation): Add Middy.js middleware for JSON Schema validation (#3694)
• 34d917e chore(deps): bump @​types/node from 22.13.8 to 22.13.9 (#3695)
• 23eebe4 feat(logger): Flush buffer on uncaught error in Middy middleware (#3690)
• 58f376e chore(deps): bump the aws-cdk group across 1 directory with 2 updates (#3687)
• 9839e13 chore(deps): bump squidfunk/mkdocs-material from 2615302 to 047452c in /d...
• 0693f71 chore(deps): bump mkdocs-material from 9.6.5 to 9.6.7 in /docs (#3686)
• ae6b7cf feat(validation): add @​validator decorator for JSON Schema validation (#3679)
• Additional commits viewable in compare view

Updates @aws-lambda-powertools/tracer from 2.15.0 to 2.16.0

Release notes

Sourced from @​aws-lambda-powertools/tracer's releases.

v2.16.0

Summary

We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush them automatically on error or manually as needed.

We also fixed a bug in the Batch Processing utility that prevented SQS FIFO messages from the same group to be processed correctly during retries

Finally, we now publish our Lambda layers to three new regions Mexico (mx-central-1), Thailand (ap-southeast-7), and Malaysia (ap-southeast-5).

⭐️ Thanks to @​VatsalGoel3 and @​ConnorKirk for their significant contributions to this release!

New Log Buffering feature

Docs

You can now enable log buffering by passing logBufferOptions when initializing a new Logger instance. This feature allows you to:

• Buffer logs at the WARN, INFO, DEBUG, and TRACE levels
• Automatically flush logs on error or manually as needed
• Reduce CloudWatch costs by decreasing the number of emitted log messages

Configuration options

Option	Description	Default
maxBytes	Maximum size of the buffer in bytes	20480
minLevel	Minimum log level to buffer (more verbose levels are also buffered)	DEBUG
flushOnErrorLog	Whether to flush buffer when an error is logged	true
enabled	Whether log buffering is enabled	N/A

When log buffering is enabled, you can now pass a new opt-in flushBufferOnUncaughtError flag to the injectLambdaContext() class method decorator and Middy.js middleware. When enabled, 1/ we'll intercept any error thrown, 2/ flush the buffer, and 3/ re-throw your original error. This enables you to have detailed logs from your application when you need them the most.

For detailed explanations with diagrams, please refer to our comprehensive documentation.

Buffering FAQs

Q: Does the buffer persist across Lambda invocations? A: No. Each Lambda invocation has its own buffer. The buffer initializes when the Lambda function is invoked and clears after function completion or manual flushing.

Q: Are my logs buffered during cold starts? A: No. We never buffer logs during cold starts to ensure all logs from this phase are immediately available for debugging.

Q: How can I prevent log buffering from consuming excessive memory? A: You can limit the size of the buffer by setting the maxBytes option in the logBufferOptions constructor parameter. This will ensure that the buffer does not grow indefinitely and consume excessive memory.

Q: What happens if the log buffer reaches its maximum size?

... (truncated)

Changelog

Sourced from @​aws-lambda-powertools/tracer's changelog.

2.16.0 (2025-03-07)

Bug Fixes

• batch: clear message group references after request (#3674) (270115e)
• ci: Update layer balance scripts (#3660) (aa14637)
• parser: envelope sub-path exports regression (#3667) (beac102)
• parser: update S3 Event Schema (#3671) (c14c7b3)

Features

• logger: Enable log buffering feature (#3641) (8203016)
• logger: flush buffer on uncaught error decorator (#3676) (28db2e3)
• logger: Flush buffer on uncaught error in Middy middleware (#3690) (23eebe4)
• logger: refresh sample rate calculation before each invocation (#3672) (8c8d6b2)
• validation: add @​validator decorator for JSON Schema validation (#3679) (ae6b7cf)
• validation: Add Middy.js middleware for JSON Schema validation (#3694) (443202b)
• validation: implement validate function (#3662) (f55127b)

Commits

• 540a14b chore(ci): bump version to 2.16.0 (#3702)
• 1ca4b26 refactor(logger): align implementation to spec + docs (#3701)
• 1a48d2c chore(deps): bump jinja2 from 3.1.5 to 3.1.6 in /docs (#3698)
• 443202b feat(validation): Add Middy.js middleware for JSON Schema validation (#3694)
• 34d917e chore(deps): bump @​types/node from 22.13.8 to 22.13.9 (#3695)
• 23eebe4 feat(logger): Flush buffer on uncaught error in Middy middleware (#3690)
• 58f376e chore(deps): bump the aws-cdk group across 1 directory with 2 updates (#3687)
• 9839e13 chore(deps): bump squidfunk/mkdocs-material from 2615302 to 047452c in /d...
• 0693f71 chore(deps): bump mkdocs-material from 9.6.5 to 9.6.7 in /docs (#3686)
• ae6b7cf feat(validation): add @​validator decorator for JSON Schema validation (#3679)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions