graphql 2021-10-13 | Slack Archive

jcf09:10:59

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…

jcf09:10:38

It looks like an error function is called whenever a resolver fails to adhere to the GraphQL schema.

jcf09:10:23

I haven't found a nice way of hooking into the executor yet. 🙂

jcf09:10:51

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

jcf09:10:30

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

thumbnail10:10:43

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 🙂

👍 2

Lennart Buit10:10:47

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).

👀 1

jcf11:10:21

Thanks, @UHJH8MG6S @UDF11HLKC! I'll probably go the interceptor route as you suggest. 👍

2021-10-13

Channels