Clojurians Log v2
graphql 2021-10-13
Have any Lacinia users here run into resolvers returning null values for non-nullable fields?
When I've encountered this, it's typically a bug somewhere else in the code (a recent example that comes to mind was an UPDATE operation inside a mutation that would only return a row from the database the first time it was called 😬).
What I'm wondering is how other people keep track or ideally prevent these issues from going unnoticed. I was thinking of hooking into Lacinia to track when a resolver is misbehaving so it gets spotted by the team building the API rather than the team consuming it…
It looks like an error function is called whenever a resolver fails to adhere to the GraphQL schema.
I haven't found a nice way of hooking into the executor yet. 🙂
I think this is where the null check can be found: https://github.com/walmartlabs/lacinia/blob/e89792945667ba6dc842c9788b896d8bb2636283/src/com/walmartlabs/lacinia/schema.clj#L1204
I see there's a callback inside the execution context but I'm not sure that's data I get to play with. https://github.com/walmartlabs/lacinia/blob/e89792945667ba6dc842c9788b896d8bb2636283/src/com/walmartlabs/lacinia/schema.clj#L947
You could check the return value in an interceptor, if any top-level errors are present, and report it to a system like syntry or rollbar.
In our system top-level errors are generally problems we want to know 🙂
Although, when you do so, you will get both schema level errors (“This field is null and cant be”) as well as user level errors (resolvers that use resolve/with-error or anything).
Thanks, @jeroen.dejong @lennart.buit! I'll probably go the interceptor route as you suggest. 👍