我有一个简单的AWS Lambda函数，可以对保存到S3存储桶的图像进行一些验证。我正在使用async.waterfall下载图像并对其进行处理，但在我输入第一个瀑布函数之前，我对从S3 PutObject触发器获取的事件数据进行了一些基本验证，特别是大小信息（{ {1}}）。如果事件引用的图像大于我的MAX_SIZE，我使用event.Records[0].s3.object.size来结束执行。
这一切都运行正常，但我在日志中注意到，在记录错误后，该函数会在退出之前继续运行一段时间。例如，我的async.waterfall调用中的第一个函数被调用（即来自该函数的消息显示在日志中）。我甚至尝试在context.fail之后立即添加context.fail(new Error("Validation error: the file is too big."))，并执行它（即我传入的消息被记录）以及几行代码。
这是预期的行为吗？我在文档中找不到任何提及。该函数是否需要一点时间退出，或者我是否误解了context.done(errorMessage)之前的处理函数中代码的同步性？
以下是我的一些代码。 async.waterfall之后显示的所有console.log消息都会打印到日志中，这是我不希望发生的。
context.fail答案 0 :(得分：11)
我相信aws lambda结构已经改变了一点，因为这个问题被问到了（詹姆斯回答）。
现在处理程序还有一个third argument，'回调'，可以调用它来停止执行脚本。根据您的调用方式，它会成功退出流程或出错。有关详细信息，请参阅这些文档。
此外，请查看上下文属性callbackWaitsForEmptyEventLoop。它默认为true，但您需要将其设置为false，以便在调用回调后，节点进程不会等待运行时循环清除，即您的异步调用将被丢弃。
答案 1 :(得分：2)
即使没有详细记录，它似乎也是预期的行为。 context documentation确实说fail()“表示失败”但不承诺停止进一步执行。
<强> context.fail（）
表示Lambda函数执行并且所有回调都未成功完成，从而导致处理异常。
您的代码的好消息是，在调用return以避免进一步处理后，context.fail()函数应该相当容易。