Fork me on GitHub
#pathom
<
2021-10-04
>
markaddleman14:10:00

I have a resolver with output [:x :y :z]. If the resolver cannot compute the result, should it return nil or {:x nil :y nil :z nil} ? I'm asking because, currently, my resolver is returning nil and that causes an Insufficient data calling resolver... error deeper in the plan. However, if the resolver returns {:x nil :y nil :z nil}, the plan is executed successfully. If it's important, I'm running in strict mode. If this is expected behavior, that's fine but a little inconvenient. If it's not expected, I can put together a repro case.

dehli14:10:59

it depends on how you want downstream resolvers to behave. If you wanted to execute downstream resolvers w/ nil values then you should return {:x nil :y nil :z nil} If you don’t want them to execute unless there’s a value, then return nil (and pathom won’t be able to execute downstream resolvers that take x, y, or z as input).

markaddleman14:10:06

I have multiple resolvers that output [:x :y :y] . I want the next resolver in the OR to run. I think that means returning nil

dehli14:10:17

yep! i think that’s what you want to do

markaddleman14:10:41

Thanks. I'll double check that other resolvers get a chance to run

cyppan14:10:26

In my understanding Pathom doesn’t care about values, only keys, so if you return {:x nil} or {:x :something} it’s the same for its graph plan, the dependent resolver taking :x as an input will be executed in both cases. But if you return nil without the keys (which is fine, it’s just different semantics) you have to explicitly handle optionality on the resolver which depend on this input with (pco/? :x). Otherwise, in strict mode, the graph plan step will fail to find the path.

wilkerlucio15:10:44

@U2845S9KL if you return nil, pathom considers that key realized, and wont try to call other resolvers to fulfill it, in case of not a key, then pathom will try the next OR option

wilkerlucio15:10:04

@U0CL38MU1 you semantic description is on spot

✌️ 1
markaddleman17:10:30

It turns out I had a resolver with an incorrectly specified output. It declares that it returned :x and :y. It successfully ran before the :x :y :z resolver which caused Pathom to go through a quite a journey to try to obtain :z. I feel like there is a bug in Pathom's plan execution because I think it should have eventually back tracked to find the :x :y :z resolver.

markaddleman17:10:14

I'll try and form a repro case. More likely, I'll end up discovering more badly specified resolvers :)

markaddleman17:10:08

One thing that would have helped me track this down earlier: when Pathom fails to generate a plan or encounters a problem during execution, it would be helpful if it could generate a plan anyway (or the plan it has computed so far) so the plan can be displayed in the Visualizer

wilkerlucio18:10:08

yeah, I agree we need more details on the failure case to help debugging, would love to collect a few examples cases like this, so we can start working a better reporting from those examples

markaddleman18:10:08

Cool. I'll provide some repro cases