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
const specificNode = this.nodes.get(path.join('.'));
if (specificNode) {
node = specificNode;
} else {
this.logger.warn(
`Could not find node with path ${path.join(
'.',
)}; defaulting to put errors on root node.`,
is supposed to be a "can't happen" case, but it can happen. Nodes are added to this.nodes by willResolveField. There's no specific callback that adds list elements to this.nodes; they get there when some field below them is resolved. But if an error occurs associated with (by err.path) a list element rather than a field, the list element won't have a node and this path is triggered, spewing a warning and losing the correct location for the error.
This was reported by a user, and by code inspection I believe that there are a lot of ways for errors to be generated with a path that ends in a list element:
a resolver can return a list containing a Promise that rejects
a resolver whose return type is [X!] can return a list containing null
a resolver whose return type is a list of union or interface elements can return a list containing an element that cannot be resolved to an appropriate object type
This list is nonexhaustive.
The text was updated successfully, but these errors were encountered:
The fix is probably just to call newNode (converting the array to the ResponsePath linked list) from addProtobufError instead of redirecting to the root.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.
This
else
path in treeBuilder.ts:is supposed to be a "can't happen" case, but it can happen. Nodes are added to
this.nodes
bywillResolveField
. There's no specific callback that adds list elements tothis.nodes
; they get there when some field below them is resolved. But if an error occurs associated with (by err.path) a list element rather than a field, the list element won't have a node and this path is triggered, spewing a warning and losing the correct location for the error.This was reported by a user, and by code inspection I believe that there are a lot of ways for errors to be generated with a
path
that ends in a list element:[X!]
can return a list containing nullThis list is nonexhaustive.
The text was updated successfully, but these errors were encountered: