I've been playing around a little with some of these examples. And I have completely fallen in love with the serverless architecture and this repo is invaluable to a newcomer. But I have encountered some code that might be misleading.
It started out with an issue (#4119) I filed on serverless/serverless. I was mislead about the error responses always returning a 502 Bad Gateway-response, even though I expected something like a 404 Not Found-response. And I found the code in some of the examples here.
But the way I was told to return a correct error response – e.g. a 404 Not Found – was to NOT call callback(new Error('[404] Not Found')) (the error as the first argument), but return it as you would return a normal 200 OK-response, but with an other status code: callback(null, { statusCode: 404, headers: { 'Content-Type': 'text/plain' }, body: 'Not Found' }).
At least this is the way to do it if one is using the standard lambda-proxy-integration, and not the more customizable lambda-integration, which I have not experimented with yet.
So I was wondering – should this be corrected?
If you think so, I would be willing to try to hunt down those error-callbacks and fix them so that they return the correct responses to the users.
I have made an example of how it might be rewritten. It's in the aws-node-github-webhook-listener-example in my fork (actual commit).
As far as I can tell this works as expected.
And as I've said, I would be willing to help out!
I've been playing around a little with some of these examples. And I have completely fallen in love with the serverless architecture and this repo is invaluable to a newcomer. But I have encountered some code that might be misleading.
It started out with an issue (#4119) I filed on serverless/serverless. I was mislead about the error responses always returning a
502 Bad Gateway-response, even though I expected something like a404 Not Found-response. And I found the code in some of the examples here.But the way I was told to return a correct error response – e.g. a
404 Not Found– was to NOT callcallback(new Error('[404] Not Found'))(the error as the first argument), but return it as you would return a normal200 OK-response, but with an other status code:callback(null, { statusCode: 404, headers: { 'Content-Type': 'text/plain' }, body: 'Not Found' }).At least this is the way to do it if one is using the standard
lambda-proxy-integration, and not the more customizablelambda-integration, which I have not experimented with yet.So I was wondering – should this be corrected?
If you think so, I would be willing to try to hunt down those error-callbacks and fix them so that they return the correct responses to the users.
I have made an example of how it might be rewritten. It's in the
aws-node-github-webhook-listener-example in my fork (actual commit).As far as I can tell this works as expected.
And as I've said, I would be willing to help out!