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?
It is not; if you can, please add a bug and I'll look into it.
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.
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 š
Whatās odd is that thereās a test, but it wasnāt executed. Not sure why.
Nope, thereās a test that passes at command line and fails inside Cursive. Funny that.
Ok, Iām very confused today.
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.
See select-bypass-if-nil near line 1174
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).