-
We primarily use TypeScript and have traditionally instantiated LambdaLog instances at the module level for use throughout out lambda's execution. For example: import { LambdaLog } from 'lambda-log';
const log = new LambdaLog();
export async function handler (event: ...) {
log.info('Received event', { event });
...
} However, while looking through CloudWatch logs recently to diagnose an issue, I've seen a couple instances where there was stale meta state in the log. To be specific, there were log messages early in the lambda's run (like the initial message in the example above) that had meta properties that they couldn't possibly have yet. Ones that are set farther down in the code. The only theory that would seem to make sense is that AWS is reusing Node execution environments so that module-level constant is retaining state from previous executions. Has anyone else seen this? If so, how have you dealt with it? For now, I'm just going to bring the instantiation of LambdaLog inside my lambda handler. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
You are correct, AWS does reuse the Node execution environment for subsequent executions to help alleviate the "warm-up" of spinning up a new execution environment. What you've described is a pretty common issue within Lambda that most developers do not account for; it's not what you would think any Node app to do, especially a Lambda function. The solution for stale data is exactly as you described. I've written some lambda functions where I needed to move multiple ESM: import { LambdaLog } from 'lambda-log';
export async function handler(event) {
const log = new LambdaLog();
log.info('Received event', { event });
} CJS: const { LambdaLog } = require('lambda-log');
module.exports = async function handler(event) {
const log = new LambdaLog();
log.info('Received event', { event });
}; I'll look into adding this into the documentation as well! |
Beta Was this translation helpful? Give feedback.
You are correct, AWS does reuse the Node execution environment for subsequent executions to help alleviate the "warm-up" of spinning up a new execution environment. What you've described is a pretty common issue within Lambda that most developers do not account for; it's not what you would think any Node app to do, especially a Lambda function.
The solution for stale data is exactly as you described. I've written some lambda functions where I needed to move multiple
require
s inside of the handler function to ensure I create a new instance for each run. The same will need to happen for LambdaLog if you are providing execution-specific options, such asmeta
, to the constructor.ESM: