1
votes

I used to get the errors object in AppSync response and a 5xx status code - if there was an error thrown from Lambda resolver (either a timeout error or a handled error I send as the first parameter in the lambda callback)

Eg. `callback(errorMessage, …)

I can no longer see the errors object in AppSync – even though the Lambda resolver is throwing errors.

Is this a change in implementation or a bug?

I'm having to work around this by changing the response mapping template in AppSync resolver – to use $util.error based on a flag in the Lambda response. While doing this – I'm able to get the errors object in AppSync response – but it’s still a 200 OK response.

Any way we can override this status code in AppSync?

1

1 Answers

0
votes

Have you changed the version of mapping template that you are using from 2017-02-28 to 2018-05-29? The behavior on how invocation errors are handled changes between the two versions.

A snippet from the AppSync Developer Docs:

Previously, with 2017-02-28, in case of an invocation error, the response mapping template was evaluated and the result was placed automatically in the errors block of the GraphQL response.
With 2018-05-29, we can now choose what to do with the error, re-raise it, raise a different error, or append the error while return data.

You can find the AppSync Developer Docs that I am referencing here.

Currently you cannot customize the error status code in AWS AppSync. The suggested approach is to use errorType in the error response. You can use $util.appendError or $util.error methods in your velocity mapping template to define the error type.