You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For most plugin hooks, an error thrown from the hook results in an "Internal Server Error" response to the client. I'd like to propose that if a plugin throws a GraphQLError instance, Apollo Server should consider that to mean "the plugin's author intended for the client to get this error as a response to their query", and handle it similarly to how such an error would be handled if it came from a resolver - namely, to be processed by the sendErrorResponse() function and not masked by an internal server error.
I understand the discussions in #7278 and #7375 and my specific use-case cannot be solved from within the context factory function. The hook I need to use is responseForOperation; while that does allow me to return a response directly, going that route when I need to respond with an error means that I lose the existing logic for error handling which Apollo already implements (call didEncounterErrors hooks, properly format errors in the response, including - or not including, as per server configuration - the stack trace etc). And more importantly, my specific use-case isn't even all that relevant - I believe that there may be use cases for most request lifecycle hooks where a plugin might want to terminate the execution of a particular request and return a meaningful error message to the user, and there is currently no sane way to do that. Allowing errors which are instances of (a descendant of) GraphQLError to pass through to the client seems like a decent tradeoff between security against unexpected errors and flexibility for plugin authors.
The text was updated successfully, but these errors were encountered:
For most plugin hooks, an error thrown from the hook results in an "Internal Server Error" response to the client. I'd like to propose that if a plugin throws a
GraphQLError
instance, Apollo Server should consider that to mean "the plugin's author intended for the client to get this error as a response to their query", and handle it similarly to how such an error would be handled if it came from a resolver - namely, to be processed by thesendErrorResponse()
function and not masked by an internal server error.I understand the discussions in #7278 and #7375 and my specific use-case cannot be solved from within the context factory function. The hook I need to use is
responseForOperation
; while that does allow me to return a response directly, going that route when I need to respond with an error means that I lose the existing logic for error handling which Apollo already implements (calldidEncounterErrors
hooks, properly format errors in the response, including - or not including, as per server configuration - the stack trace etc). And more importantly, my specific use-case isn't even all that relevant - I believe that there may be use cases for most request lifecycle hooks where a plugin might want to terminate the execution of a particular request and return a meaningful error message to the user, and there is currently no sane way to do that. Allowing errors which are instances of (a descendant of)GraphQLError
to pass through to the client seems like a decent tradeoff between security against unexpected errors and flexibility for plugin authors.The text was updated successfully, but these errors were encountered: