Got a Node.js Lambda handling Genesys Cloud interaction events. The function times out at 30s when processing large transcripts, causing a 408 on the webhook retry.
exports.handler = async (event) => {
const payload = JSON.parse(event.body);
// processing logic here
};
Payload size is hitting the 6MB Lambda limit. Need to stream the body instead of parsing it all at once. How do I handle the stream correctly in the handler?
The issue here isn’t just the 6MB limit, it’s how you’re handling the event.body in Node.js 18+ Lambda runtimes. The docs state: “For Node.js 18.x, AWS Lambda automatically enables the HTTP API payload format version 2.0, which includes raw body data.”
If you’re parsing JSON.parse(event.body) and the body is a stream (which it is for large payloads), you’re blocking the event loop trying to read the whole thing into memory. You need to handle the isBase64Encoded flag and process the buffer correctly.
Here’s how you handle the stream without blowing up memory:
const { createHash } = require('crypto');
exports.handler = async (event) => {
// Check if the body is base64 encoded (common for binary or large text payloads)
let payload;
if (event.isBase64Encoded) {
// Decode the base64 string to a buffer, then to UTF-8 string
const buffer = Buffer.from(event.body, 'base64');
payload = buffer.toString('utf-8');
} else {
// For smaller payloads, it might just be a string
payload = event.body;
}
// Now parse the JSON. This still loads into memory, but it's safer.
// To truly stream, you'd need to write to S3 or use a step function,
// but for < 10MB, this buffer approach is usually fine in Lambda.
try {
const data = JSON.parse(payload);
// Process your transcript chunks here
const transcript = data.transcript;
console.log(`Received transcript of length: ${transcript.length}`);
return {
statusCode: 200,
body: JSON.stringify({ message: 'Processed' })
};
} catch (error) {
console.error('Error parsing payload:', error);
return {
statusCode: 400,
body: JSON.stringify({ error: 'Invalid payload' })
};
}
};
If you’re still hitting timeouts, the problem might be the Genesys Cloud webhook retry logic. The docs state: “Webhooks will retry failed deliveries up to 5 times with exponential backoff.” Your Lambda is timing out because it’s waiting for the full parse to complete before it can send a 200 OK.
Consider moving the heavy lifting to SQS. Push the payload to SQS in the Lambda, then have a separate processor handle the transcript analysis. This keeps the Lambda cold start fast and avoids the 30s timeout trap.
Also, check your OAuth token expiration if you’re making API calls from within the Lambda. The docs state: “Access tokens are valid for 30 minutes by default.” If your Lambda is invoked less frequently than that, you might be hitting 401s on the backend calls, which adds to the timeout.