Content edit of error reporting article #4926
Conversation
There was a problem hiding this comment.
Realizing that I actually don't understand AS errors too deeply and might not be best situated to review this. Maybe @trevor-scheer ?
docs/source/data/errors.mdx
Outdated
|
|
||
| import {ExpansionPanel} from 'gatsby-theme-apollo-docs'; | ||
|
|
||
| Whenever Apollo Server encounters errors while processing a GraphQL operation, its response to the client includes an `errors` array that contains each error that occurred. Each error in the array has an `extensions` field that provides additional useful information, including an error `code` and an `exception.stacktrace`. |
There was a problem hiding this comment.
perhaps
and (in development mode) an
exception.stacktrace
?
docs/source/data/errors.mdx
Outdated
|
|
||
| ## Masking and logging errors | ||
|
|
||
| > To disable stacktraces for production, pass `debug: false` to the Apollo Server constructor or set the `NODE_ENV` environment variable to 'production' or 'test'. Note that this will make the stacktrace unavailable to your application. If you want to log the stacktrace, but not send it in the response to the client, see [Masking and logging errors](#masking-and-logging-errors) below. |
There was a problem hiding this comment.
It looks a little weird that this entire subsection is a block quote. Is that intentional?
Also I feel like this could be more from a perspective of "stacktraces are on in dev and off in production, by which we mean NODE_ENV is such and such. you can override this by specifying debug: true or debug: false explicitly", if that makes sense?
I also have no clue why they are off by default in test, that seems weird and not particularly explained when it was added in 0e68e2e
There was a problem hiding this comment.
Ah this must be a block I moved while planning to rework, and then forgot about
StephenBarlow
force-pushed
the
sb/error-docs
branch
from
7e0614b
to
1942910
Compare
|
Edits LGTM but again I'm not really an expert |
docs/source/data/errors.mdx
Outdated
| const resolvers = { | ||
| Query: { | ||
| userWithID: (parent, args, context) => { | ||
| if (args.id <ExpansionPanel 1) { |
There was a problem hiding this comment.
Stray paste I suppose
| if (args.id <ExpansionPanel 1) { | |
| if (args.id < 1) { |
docs/source/data/errors.mdx
Outdated
| const resolvers = { | ||
| Query: { | ||
| userWithID: (parent, args, context) => { | ||
| if (args.id <ExpansionPanel 1) { |
There was a problem hiding this comment.
| if (args.id <ExpansionPanel 1) { | |
| if (args.id < 1) { |
docs/source/data/errors.mdx
Outdated
| if (err.message.startsWith("Database Error: ")) { | ||
| return new Error('Internal server error'); | ||
| } |
There was a problem hiding this comment.
Nit: use same quote type from one string to the next
docs/source/data/errors.mdx
Outdated
| }, | ||
| ``` | ||
|
|
||
| > To make context-specific adjustments to the error received by `formatError` (such as localization or personalization), consider [creating a plugin](../integrations/plugins/) that uses the `didEncounterErrors` lifecycle event to attach additional properties to the error. These properties can be accessed from `formatError`. |
There was a problem hiding this comment.
I was going to suggest a link specifically to the didEncounterErrors heading on the page, but there's really not much there. Adding an example on modifying errors via that hook would be great as a follow up since visiting that documentation doesn't tell me anything about what I can actually do there. i.e. I wouldn't assume it's ok for me start tacking on properties in that hook.
There was a problem hiding this comment.
Cool, I'll add a link anyway, and will make a note to return to this doc soon with an example
StephenBarlow
force-pushed
the
sb/error-docs
branch
from
1942910
to
4937478
Compare
No description provided.