I have a lambda function that is invoked when a cognito user submits their verification code.
PostConfirmation failed with error RequestId: 3241xxxx-3cxx-11xx-aexx-8b39059xxxxx Process exited before completing request.
at constructor.e (<anonymous>:21:4685)
at constructor.callListeners (<anonymous>:21:24558)
at constructor.emit (<anonymous>:21:24267)
at constructor.emitEvent (<anonymous>:21:18671)
at constructor.a (<anonymous>:21:14521)
at d.runTo (<anonymous>:22:12444)
at <anonymous>:22:12651
at constructor.<anonymous> (<anonymous>:21:14731)
at constructor.<anonymous> (<anonymous>:21:18726)
at constructor.callListeners (<anonymous>:21:24664)
And my lambda function's job is to receive that submission and publish a message to SQS, and then continue.
module.exports.trigger_userVerified = (event, context, callback) => {
const AWS = require('aws-sdk');
var nickname = event.request.userAttributes.nickname;
var params = {
MessageBody: 'A user has registered an account and has supplied a website address.',
QueueUrl: ' https://sqs.us-east-1.amazonaws.com/xxx/my_sqs_queue',
DelaySeconds: 0,
MessageAttributes: {
'nickname': {
DataType: 'String',
StringValue: nickname
}
}
};
sqs.sendMessage(params, function(err, data) {
if (err) console.log(err, err.stack); // an error occurred
context.done(null, event);
});
};
Is there something wrong with the way I'm handling this lambda function that causes this error? how do I investigate further?
The error "Process exited before completing request" means that the lambda Javascript function exited before calling context.done (or context.succeed, etc.). Most of the times this means that there is an error in the function.
I'm not a Javascript expert (at all) so there may be more elegant ways to find the error but my approach has been to put a bunch of console.log messages in my code, run it, and then look at the logs. I can usually zero in on the offending line and, if I look at it long enough, I can usually figure out my mistake.
Since it's lambda:
Please check your cloudwatch logs and see if you can find more. In your place I would add some console.log statements as well.
Related
CURRENTLY
I am trying to get AWS Textract working on a Lambda function and am following documentation on https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Textract.html#analyzeDocument-property
My Lambda code:
"use strict";
const AWS = require("aws-sdk");
exports.handler = async (event) => {
let params = JSON.parse(event.body);
console.log("Parse as document...");
let textract = new AWS.Textract();
let doc = params["doc"];
let config = {
Document: {
Bytes: doc,
}
};
textract.analyzeDocument(config, function (err, data) {
console.log("analyzing..."); //<-- nothing logged to console if no error
if (err) {
console.log(err, err.stack);
}
// an error occurred
else {
console.log("data:" + JSON.stringfy(data)); //<-- nothing logged to console if no error
} // successful response
});
console.log("Finished parsing as document.");
};
ISSUE
I cannot get the data back from Textract. It seems I am unable to get the callback working entirely. What's odd is if there is an error e.g. my configuration is wrong, the error handling of the callback will print the log and "analyzing..." log, but without error, none of the logs in the callback print.
Current Logs:
Parse as document...
Finished parsing as document.
Expected / Desired Logs:
Parse as document...
analyzing...
data:{textract output}
Finished parsing as document.
Please help!
NOTES
I am using a role for that Lambda that allows it to access Textract.
I get the same result whether I include the HumanLoopConfig settings or not.
Solved, apparently I needed to setup a promise:
let data = await textract.analyzeDocument(config).promise()
console.log("data:"+data );
console.log("Finished parsing as document.")
I'm trying to debug a problem that I think is being caused by an uncaught error in an async process. This is simple example that simulates the type of error I'm trying to detect:
async function test(event, context) {
console.log('I can find this log message');
context.callbackWaitsForEmptyEventLoop = false;
setTimeout(() => {
console.log('I cannot find this one');
throw new Error('uh oh'); // I don't see this in CloudWatch, either
}, 1000);
return {};
}
I know the lambda is frozen after the function returns, so I'm guessing there's no way to see these errors/logs.
Is there anything I can do to try to detect what is still in the event loop when the handler returns so I might be able to track down an unhandled error like this one?
You can use subscribe to the unhandled rejections.
process.on('unhandledRejection', error => { // log error});
hope this helps.
I am trying to deploy a simple Slack lambda api which uses the #slack/client library to remove members and pinned messages from a specific channel. The issue that I am running into is the function executes without a problem, and it is removing the channel members without a problem, but my Lambda function keeps returning:
HTTP/1.1 502 Bad Gateway
...
X-Cache: Error from cloudfront
...
{
"message": "Internal server error"
}
as the response body. When I check the logs using sls logs -f api, I dont see any errors there either. I see the console.log of my function successfully executing.
My serverless.yml is as follows:
provider:
name: aws
runtime: nodejs10.x
profile: serverless
functions:
api:
handler: handler.api
timeout: 30
events:
- http:
method: POST
path: clean
And my api code, i have removed the unnecessary function codes as they are doing their work, is :
module.exports.api = async (event, context, callback) => {
let channel = JSON.parse(event.body).ctf
let id = await findChannelId(channel)
removeMembersFromChannel(id[0]).then(() => {
removePinsFromChannel(id[0]).then(() => {
callback(null, {
statusCode: 200,
body: JSON.stringify({
message: `Cleaned ${channel} ${id}`,
}, null, 2),
})
})
})
};
Things I have tried:
returning the response instead of using the callback
using promises and async await
testing the function locally using sls invoke local
most of my search shows that this could be a permission issue, but all the references are for s3 usage which is something i am not using.
Questions
Why am I getting this error, and how I can resolve this?
After referenceing this In the handler function, I am using JSON.stringify. Using the serverless-framework, how can i avoid using Lambda proxy integration?
Please, add console.log for detailed logging via cloudwatch and use x-ray. Some typical problems with cloudfront:
- a lot of time to propagate to edge locations (maybe u need recreate your cdn)
- logs from lambda#edge locates in invoked region
I'm trying to call one Lambda function from another one that I have. I set up my permissions so that is not problem.
My problem is that the function doesn't wait for the Invoke function to complete and return NULL all the time.
Here is the code I'm using:
const AWS = require('aws-sdk');
exports.handler = async (event, context, callback) => {
var lambda = new AWS.Lambda({region: 'us-east-1', apiVersion: '2015-03-31'});
var params = {
FunctionName: 'testFunction',
InvocationType: 'RequestResponse'
}
lambda.invoke(params, function(err, data){
console.log(err);
console.log('here');
}).promise().then(data=> { callback(null, {message:'done'}); });
};
The {message:'done'} its never shown. I was recommended to use invokeAsync but that function is deprecated by AWS.
I know the problem is that the function is running lambda.invoke as synchronously because if I add callback(null, {message:'done'}); outside of the lambda.invoke function then I can see the console.logs working.
Any help?
TL;DR - Remove "async" in line 3, and it should work.
Your issue seems to be caused by the async keyword here. I have recreated this and deployed it to Lambda to run on Node v8.10 (but pointing it to invoke one of my own lambda functions of course).
Why are you using "async" here anyway? The async keyword declaration defines an asynchronous function and returns an AsyncFunction object. AWS Lambda is expected a function, not an AsyncFunction, and your "null" result is probably just Lambda immediately giving up because it can't find a regular function. Also, async is almost exclusively used with await (at least is was in 99% of the cases I've seen), and since your code isn't using await at all I don't see any reason to use async either.
I'm new to AWS, and Lambda intricacies in particular. My current goal is to get a Lambda function listening to a Kinesis stream. What I'm curious about is, in the case of a Kinesis stream triggering a Lambda function, who is the caller (for purposes of the Lambda's export.handler callback)? In other words, when the callback is executed on success in the Lambda, who is the caller that receives the success message? And would this ever be used?
e.g., the starting template for a blank Lambda function:
exports.handler = (event, context, callback) => {
callback(null, 'Hello from Lambda');
// the second arg of this callback is the success message;
// in the case of a Kinesis trigger, who receives it?
};
The idea is if the record was successfully processed, you should callback with statusCode 202 to let kinesis know it was a success so that the record is removed from the stream. However, if it failed to process the record, callback with a different statusCode, in which case the record will be re-tried at a later time. After 24 hours, and if it's still unsuccessfully processed the record will be removed.
For example:
if (success) {
callback(null, {
statusCode:200,
body: "Record was successfully processed"
})
} else {
callback(null, {
statusCode: 404,
body: "Record was not successfully processed"
})
}
The caller of Lambda would be Kinesis and if you don't use the callback, the function will execute till its timeout, costing you more on Lambda running time. Therefore exit routine is needed, when your execution is complete.