malformed proxy response with middy, but works with serverless invoke local

Hi Thanks. Currently no support plan :/. We found 2 workarounds for the issue: either stop using middy or wrap middy with a function expression:

const handler = middy(targetHandler).use(someMiddleware());
const wrappedHandler = async (event, context) => {
      return handler(event, context);
 };

export { wrappedHandler };

From the experiments, we found that the same corrupted behavior happens if middy is wrapped with the following function expression:

const wrappedHandler = async (event, context, callback) => {
      return handler(event, context, callback);
 };

I think adding callback in the function expression made Lambda expect us to use it to return output from lambda. Middy instance as well expects callback as 3rd param. I do not know what happened Lambda started to interpret the handler in a different way. Or maybe I miss something here? I will be grateful for more suggestions.

Just a guess: If you are using async function calls within a Lambda function you must make sure that they complete before the Lambda function exits. The Lambda service doesn't know that an async call hasn't completed so it can prematurely terminate your function and in that case the returned data from the Lambda function will be incomplete. It's possible that there is a timing issue here where it used to work but under load (maybe?) the timing slips a bit and then your Lambda errors out.

I would say everything is properly awaited. What you say does not explain lambda behavior when middy wrapper is applied. Other thing is what you mean under load? many of our lambdas were affected at the same moment. Middy contributors share suspicions about how "callback" in function expression might be interpreted by Lambda https://github.com/middyjs/middy/issues/1005