feat(event-handler): add support for error handling in AppSync GraphQL

[arnabrahman]

Summary

This PR adds support for error handling in AppSync GraphQL described in the issue

Changes

• exceptionHandler method is introduced to register an exception and its handler.
• ExceptionHandlerRegistry is introduced to keep track of registered exception handlers
• exceptionHandler is also exposed as a decorator method
• Unit tests are written for 100% coverage
• Added documentation for exception handling with examples
• Minor housekeeping(ex: dockerfile nodejs version update due to error & endregion added)

Lambda handler:

import { AppSyncGraphQLResolver } from '@aws-lambda-powertools/event-handler/appsync-graphql';
import { Logger } from '@aws-lambda-powertools/logger';
import { AssertionError } from 'assert';
import type { Context } from 'aws-lambda';

const logger = new Logger({
  serviceName: 'MyService',
});
const app = new AppSyncGraphQLResolver({ logger });

app.exceptionHandler(AssertionError, async (error) => {
  return {
    error: {
      message: error.message,
      type: error.name,
    },
  };
});

app.onQuery('createSomething', async () => {
  throw new AssertionError({
    message: 'This is an assertion Error',
  });
});

export const handler = async (event: unknown, context: Context) =>
  app.resolve(event, context);

Response mapping template

#if (!$util.isNull($ctx.result.error))
  $util.error($ctx.result.error.message, $ctx.result.error.type)
#end

$utils.toJson($ctx.result)

Response:

{
  "data": {
    "createSomething": null
  },
  "errors": [
    {
      "path": [
        "createSomething"
      ],
      "data": null,
      "errorType": "AssertionError",
      "errorInfo": null,
      "locations": [
        {
          "line": 2,
          "column": 3,
          "sourceName": null
        }
      ],
      "message": "This is an assertion Error"
    }
  ]
}

Issue number: closes #4130

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
7.2% Duplication on New Code

See analysis details on SonarQube Cloud

[arnabrahman]

I have one observation: while looking into the Python documentation, I realized they also accept list of errors for exception handling. Should we support that as well?

[svozza]

I have one observation: while looking into the Python documentation, I realized they also accept list of errors for exception handling. Should we support that as well?

Yes, that's what I'm doing in the API Gateway event handler so we should be consistent:

powertools-lambda-typescript/packages/event-handler/src/rest/BaseRouter.ts

Line 57 in 92c7f36

public errorHandler<T extends Error>(

[svozza]

Is this intentional?

[arnabrahman]

Yes, as other version is failing in my local

[svozza]

The recommended way to do response mapping is JS now, not VTL, so we should include an example of how to do it that way.

[svozza]

We return null in the API Gateway handler so let's do the same here.

[svozza]

This test should have have an assertion somewhere to ensure that the this context is being preserved.

[svozza]

Do we need this function? I think it's sufficient for the client to call resolve and check whether it returns null or not.

[arnabrahman]

Yeah, that can also be done too