Any error thrown in the context have a Context creation failed: prefix, even in production environment.
Current workaround of using formatError and stripping off the prefix there, feels hacky.
I'm also having this problem!
This is by design to ensure that unhandled exceptions are handled by user code. This is a catch-all that we're putting in place to help guide you to the site of the error.
You can and should avoid this by doing own catching of errors within the context function.
I don't understand the motivation behind this. If I want to know where an exception is thrown I have a stack trace for that. I don't need the message hijacked to tell me that. In my case I am throwing my own exceptions in the context handler... so catching it there doesn't make any sense.
I would find the ability to do this useful as well.
My use case: inside the context function I am checking for a header required to be in a particular format. If this header does not match the format, then it throws an error.
I do not want to catch this error as I want it to result in Apollo responding with an error...the one I've purposefully thrown.
The Apollo Server docs itself shows an example where an error is thrown inside the context for API-wide authorization. This extra message is disruptive and doesn't help with anything, especially if you're using a second language that is not English for the error message. The stack trace already points out where the error was thrown, so it's completely useless.
Can this please be reconsidered? @glasser @abernix
Most helpful comment
I don't understand the motivation behind this. If I want to know where an exception is thrown I have a stack trace for that. I don't need the message hijacked to tell me that. In my case I am throwing my own exceptions in the context handler... so catching it there doesn't make any sense.