Fork me on GitHub
#graphql
<
2021-11-17
>
thumbnail10:11:42

Since the performance rework in lacinia (somewhere between 1.0 and 1.1-alpha5) empty / nil values are also required to be tagged with a type when returning a union. i.e. returning (resolve/resolve-as nil {:message "my error"}) will now raise "Field resolver returned an instance not tagged with a schema type.", where it'd previously work. Is this intentional?

hlship16:11:51

It is not; if you can, please add a bug and I'll look into it.

thumbnail16:11:20

https://github.com/walmartlabs/lacinia/commit/6a458c7c59a1828bf43050eebbd31c65bddf26ac#diff-3f41bbf0c9f5c2c078d7b2ceff7311e62c2c9621ede2d79462e3593274fab886L1046 I suspect it's this specific line 😬 L1046 in com.walmartlabs.lacinia.schema.clj. If you can restore that it should work again. A simple repro would be returning nil from a field which should return a union.

thumbnail20:11:56

I tried creating a repro but wasn't able so far. I'm not sure what caused the initial issue but it seems it was local. Sorry for the noise 😅

hlship02:11:01

What’s odd is that there’s a test, but it wasn’t executed. Not sure why.

hlship02:11:16

Nope, there’s a test that passes at command line and fails inside Cursive. Funny that.

hlship02:11:31

Ok, I’m very confused today.

hlship02:11:52

r.e. L1046, I’ll check again, but I believe that nil has its own path through that code so the check was no longer necessary.

hlship02:11:08

See select-bypass-if-nil near line 1174

hlship02:11:58

Anyway, I can’t reproduce the problem you are seeing; the tests (such as https://github.com/walmartlabs/lacinia/blob/44d3526905b1689b377c875e4a61bc79cba74e31/test/com/walmartlabs/lacinia/unions_test.clj#L104) cover this case AFAIK and show that it is working correctly (a nil flows through OK, even for a type defined in terms of union or interface).

1