AWS Lambda plugin is_proxy_integration vs. unhandled_status

Questions
1

Hi, found the still-undocumented is_proxy_integration feature recently added in this PR: https://github.com/Kong/kong/pull/3427 by @aloisbarreras

I’m wondering if any thought was given to how this interacts with unhandled_status option in the plugin. It seems to preempt it, as the behavior of the Lambda when it gets an Unhandled function error is to return a body with a stack trace and so forth, but no “statusCode” field. Thus the proxy integration feature makes the response a 502 Bad Gateway with the error message “could not JSON decode Lambda function response: statusCode must be a number”.

I’m not sure what the best behavior would be here, but it’s a little annoying that the stack trace and x-amz* headers get eaten by the proxy integration feature, interfering with debugging. Could the proxy integration feature check for X-Amz-Function-Error: Unhandled and maybe just pass things through unchanged?

Is there some way to work around this with the current plugin? maybe somehow preserve the X-Amz headers so you can find the trace in AWS?

2

Just thinking about this a bit more, the obvious work around is to wrap all your Lambda code in a try/catch (or equivalent), pull out any error message or stack trace from the exception and send it back along with “statusCode”: 500.

Still worth thinking about if there’s a smoother way to handle this in the plugin, though.