Closed markaddleman closed 3 years ago
fyi - If I add the following resolver, the planner succeeds and yields the correct result:
(pco/defresolver dummy [] {::pco/input [] ::pco/output [:event/id]} {:event/id nil})
Thanks for the report, I have a hunch on what's going on. Probably during the nested input planning, it's not sending the available data correct down, the first gist should be valid, I'll take a deeper look later today to confirm this.
I just did a look, but now I think Pathom is doing the correct behavior, one change to your resolvers that makes it work is changing workflow-ids->workflow-params
to let Pathom knowns there will be :event
, inside, like:
(pco/defresolver workflow-ids->workflow-params [{:workflows.workflow/keys [workflow-ids]}]
{::pco/input [:workflows.workflow/workflow-ids]
::pco/output [{:workflows.workflow/events [:event]}]}
{:workflows.workflow/events (into [] (comp
(mapcat :workflows.workflow/events)
(distinct))
workflow-ids)})
Closing for now, but please reopen if you believe some behavior needs to change, and we can discuss more.
In https://gist.github.com/markaddleman/a8ecdfbc1ec71f56511f97251cc15898 there is an example of a client query that fails when a resolver requires a join as an input but succeeds when the client queries for the same join. When the planner fails, it throws an exception with the following info:
com.wsscode.pathom3.connect.planner/unreachable-paths: #:event{:id {}} com.wsscode.pathom3.error/cause: :com.wsscode.pathom3.error/attribute-unreachable com.wsscode.pathom3.error/phase: :com.wsscode.pathom3.connect.planner/plan com.wsscode.pathom3.path/path: [:workflows.workflow/events]