Discussion of issue 97

[markaddleman]

Starting discussion from #97 (comment)

Why can Pathom resolve the join when it is in a client query but it cannot when the join is input to a resolver?

[wilkerlucio]

It's because the input check is more strict than outside queries. The version that's not input kinda works by accident because Pathom delays the plan computation for nested query parts. But for nested inputs Pathom verify the possibility ahead of time, so when we look at this resolver:

(pco/defresolver workflow-ids->workflow-params [{:workflows.workflow/keys [workflow-ids]}]
  {::pco/input  [:workflows.workflow/workflow-ids]
   ::pco/output [:workflows.workflow/events]}
  {:workflows.workflow/events (into [] (comp
                                         (mapcat :workflows.workflow/events)
                                         (distinct))
                                    workflow-ids)})

In this specification there is no way to know that workflow ids will have :event inside (both :workflows.workflow/workflow-ids and :workflows.workflow/events are opaque, in your provided data each item under events has an event, but Pathom can't know your code will move from one part to the other, so the inference is not possible). That's why we need to specification on that output to make this work.

Makes sense?

[markaddleman]

Yes, this makes sense. Thanks.

[markaddleman]

Is there a deep reason why input checks are more strict than outside queries? I think I understand why the input checks are strict: Pathom computes a plan for the query ahead of time.

For debugging purposes, it is convenient to create an EQL query that matches the input to a resolver. If Pathom computes the EQL query differently than the resolver, debugging is harder.