Most of the predefined ApolloError subclasses fail to pass through extensions to ApolloError

[bristoljon]

"apollo-server": "^2.18.2",
"apollo-server-express": "^2.24.0",

Throwing a ForbiddenError with extra fields as described here does not work and the errors array received by the client contains an extensions field with only the standard Apollo fields.

  Query: {
    hello: (root, args, context) => {
      throw new ForbiddenError("Goodbye cruel world!", {
        extra: "data",
        and: "other custom fields"
      });
    }
  }

Results in:

{
  "errors": [
    {
      "message": "Goodbye cruel world!",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "hello"
      ],
      "extensions": {
        "code": "FORBIDDEN",
        "exception": {
          "stacktrace": [...]
        }
      }
    }
  ],
  "data": {
    "hello": null
  }
}

However the extra fields do appear in the response if using a UserInputError but I would expect them to be consistent.

Perhaps this is by design but if that is the case it would be good to update the docs at url above. And we do have a use case where a ForbiddenError is the right choice semantically but we need to include extra data in the response as well.

Code sandbox: https://codesandbox.io/s/eloquent-mclean-f9v1l?file=/index.js:264-445

Thanks,

Jon

[glasser]

It looks like ForbiddenError's constructor doesn't pass through an extensions argument to its superclass like UserInputError does. Adding that (I'd say to all the ApolloError subclasses except the two persisted query ones which probably shouldn't be thrown from end-user code) sounds reasonable. Feel free to file a PR against the release-3.0 branch!