Hooking to the end of requests after throwing errors

Help
1

Hello,

I am throwing errors within graphql-js validationRules and having a hard time catching theses afterwards in Apollo.

Apollo Server will, by default, treat thrown errors as HTTP 500.
I wanted to rewrite the HTTP code using an additional plugin here but without success.

I appears that after you thrown an error, even if it’s inside graphql-js, you won’t be triggering further hooks, especially one which should always be triggered willSendResponse.

If you mind why we are throwing instead of adding errors into the current context, you can refer to this issue #193.

2

So far, it seems to happens here apollo-server/runHttpQuery.ts at 655c1ca35514683fb6364519ec53846b86400042 · apollographql/apollo-server · GitHub,

validation errors not getting caught: apollo-server/requestPipeline.ts at 5188b1ee408b5e2a983662b0f3a15283c071e522 · apollographql/apollo-server · GitHub

3

Hey @c3b5aw, thanks for the helpful writeup. I’m pretty sure Apollo Server 4 handles exactly what you’re trying to accomplish with the plugin. We’re currently in alpha with an RC around the corner. Is updating to v4 an option for you?

The updated docs with relevant info are here:

Status code and headers can now be set by plugin (as well as resolvers and by your context function).

4

Hello @trevor.scheer,

This is not really doable as we are building a plugin orchestrator.

5

Hello,

I am bumping this thread with a bit more context, I am maintaining GraphQL Armor and having issue canceling context when running into errors.
Reporting the error into the context won’t cancel the other rules/plugins and this might represent an issue itself.

I am looking for a safe way to totally cancel validation, let me know if alternatives exist.

6

Hey @c3b5aw, sorry for the delay in response.

For starters, it’s unlikely we’ll make any changes ourselves to v3 at this point that aren’t security-related. If you want to open a PR that corrects the issue, we might be open to that if it’s not too substantial of a change / doesn’t affect existing behavior.

I’m not sure why “building a plugin orchestrator” rules out v4, I’m missing some context. Does your library need to support both v3 and v4?

I don’t understand what “canceling context” means. In v4, we now have a hook contextCreationDidFail and the pipeline will stop early and respond with the error thrown from the context function (allowing you to set status code as well). Is that helpful?

In any case, if this is still an issue for you would you mind opening an issue on GH with a clear explanation of what AS does now vs. what you’re expecting?