You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Error logging is incompatible with Lambda Advanced Logging Controls #202
For Lambdas configured to log in JSON (_AWS_LAMBDA_LOG_FORMAT == LogFormat.JSON), error log messages contain the property "log_level": "ERROR". If the Lambda is configured to use log-level filtering the filtering doesn't work as expected because the log-level filtering feature makes the assumption that the message contains the JSON property level (not log_level). Lambda will assign the log output the level INFO to messages with missing (or invalid) level property, i.e. all messages created by the awslambdaric function log_error are no longer considered errors because the property log_level is simply ignored by Lambda.
Hence, if we use log-level filtering and set the level to WARN (a pretty common config for production) all error log messages created by awslambdaric (most notably uncaught handler errors) are missing in CloudWatch because they are wrongly attributed the (default) log level INFO.
We should either add the property level to the error_result or replace the property log_level with level in the error_result created by log_error(...).
I investigated this further and prepared a small patch.
The managed Python 3.14 result may be explained by the log sink used. FramedTelemetryLogSink emits errors with an ERROR frame, while the stdout fallback, StandardLogSink, writes JSON containing "log_level": "ERROR" but no "level" field.
The patch adds "level": "ERROR" while retaining "log_level" for compatibility, with a regression test. The test fails on current main (3810eed) and passes with the patch; make pr passes all 133 tests with 95.72% coverage.
I have not reproduced this end-to-end in CloudWatch or confirmed that deployed Lambda environments can use the stdout fallback. If aligning that schema is still useful, I’m happy to submit a PR.
Activity
anzheyazzz commentedon Jul 17, 2026
Hi! Thanks for raising the issue.
I did a quick test with managed runtime:
python3.14and I can see from CloudWatch, the error was correctly filtered:
My setting:
Can you share a bit more about how you setup the filtering?
maoyouaa commentedon Aug 10, 2026
I investigated this further and prepared a small patch.
The managed Python 3.14 result may be explained by the log sink used.
FramedTelemetryLogSinkemits errors with an ERROR frame, while the stdout fallback,StandardLogSink, writes JSON containing"log_level": "ERROR"but no"level"field.The patch adds
"level": "ERROR"while retaining"log_level"for compatibility, with a regression test. The test fails on currentmain(3810eed) and passes with the patch;make prpasses all 133 tests with 95.72% coverage.I have not reproduced this end-to-end in CloudWatch or confirmed that deployed Lambda environments can use the stdout fallback. If aligning that schema is still useful, I’m happy to submit a PR.
maxday commentedon Sep 14, 2026
closing as #220 has been merged