malformed proxy response since 2 days no code changes

[jakinluk]

Describe the bug
For 3 days for all redeployed stacks, we started getting malformed proxy response errors.

"httpMethod": "POST",
"status": "500",
"protocol": "HTTP/1.1",
"responseLength": "35",
"error": "Internal Server Error",
"errorResponseType": "MALFORMED_PROXY_RESPONSE",
"integrationError": "The response from the Lambda function doesn't match the format that API Gateway expects. Invalid status code",
"integrationStatus": "200",
"authorizerError": "-"

To Reproduce
Just redeploy stack/ lambda that uses middy

Expected behavior
No malformed proxy response.

Environment (please complete the following information):

• Node.js: 16
• Middy: 1.4.0
• AWS SDK 2.722.0

Additional context
When running sls invoke local everything works.
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 your help.

[willfarrell]

Thanks for reporting, and using Middy for so long, unfortunately though I'm no longer supporting middy v1.x. If I recall correctly v1 supported both callback and async/await which might be the source of the issue and why you need your wrappedHandler w/ async. I would recommend upgrading to the latest version of Middy. Note that later versions of Middy have dropped the use of callback for async/await, change the execution order of onError, and have switched to use AWS SDK v3.

If lambda is acting differently without code changes, then it's likely a change to lambda that's causing the issue (imo). I would recommend you contact AWS Support if you really don't want to push code changes.