I've considered that, I believe its possible to leverage the planner in Pathom to have the schematics on what to run, but for the runner it would do something very different, maybe generating spark statements or something

I'm not familiar with spark statements but I'll read up about it. Indeed, maybe just using the planner could be a good step in the right direction.

Ah. I should just use a more updated version, preferrably non-alpha 😅

Ah. Everything is still alpha. This same error happens for me on version 2022.04.20-alpha

hello @U7Y7601B2, yep, all alpha still 😅 can you give a me a repro? its possibly a regression, but need an example to check

(anyway, this error should never happen, its presence means there is something wrong in the planner algorithm)

Ah. Sounds worth extracting out a simple repro example from our system then.

Ok, I narrowed it down as much as I could.

(ns repro
  (:require [clojure.test :refer :all]
            [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.interface.eql :as p.eql]
            [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.connect.built-in.resolvers :as pbir]))

(pco/defresolver get-comment []
  {:comment/author {:user/id "user-id"}})

(def aliases (pbir/equivalence-resolver :comment/author :user))

(pco/defresolver user-resolver
  [{id :user/id}]
  {:user/avatar-filename "avatar-filename"})

(pco/defresolver avatar
  [{user             :user}]
  {::pco/input [{:user [:user/avatar-filename]}]}
  {:user/avatar user})

(pco/defresolver user-object-resolver
  []
  {::pco/output [{:user [:user/id]}]}
  {:user {:user/id "user-id"}})

(deftest repro-test
  (is
    (thrown?
      AssertionError
      (p.eql/process
        (pci/register [get-comment
                       aliases
                       user-resolver
                       user-object-resolver
                       avatar])
        {}
        [{:user
          [:user/avatar]}]))))

thanks, can you please open an issue in Pathom 3 repo (https://github.com/wilkerlucio/pathom3/issues)?

@U7Y7601B2 I think I understand already the bug, its a situation where a node must be removed, but the algorithm wasn't expecting the node to have parents in this case, and your repro demonstrate a case where it does happen

Pathom is trying to remove the node author->user-alias because it notices that this path can't fulfill the nested requirements

but a node can't have parents when its removed, which is correct, so I think the way to go here is to remove the whole ancestor chain as well, this would translate in the user-object-resolver being the only valid path in this scenario

Ah. Well I finished submitting the case for you 😅 https://github.com/wilkerlucio/pathom3/issues/136

@U7Y7601B2 pushed a fix to main, can you try so I can confirm the fix?

I am unfamiliar with how to bring in dependancies from an active branch rather than released :mvn/version could you point me to some docs or show me what a deps.edn import would look like?

sure, one sec

you can use this to import Pathom 3:

com.wsscode/pathom3        {:git/url ""
                              :sha     "28956c7f5d6dd259effc09567829c096932714a7"}

Oof, I was so close to doing it right. Thanks!

@U066U8JQJ That fixed it. Unfortunately for me, there are 2 other unit tests of ours that fail on updating pathom3 that are apparently unrelated. Ones with less obvious errors thrown in my face. Looks like I need to make more repros

thanks for bringing those, happy to keep debugging and tacking those with you

Yes, you need a resolver that explicitly knows how to look up a product/slug from a product/id. In your example this could be a resolver that takes :product/id and :products , then filters the products for one that matches.

The resolver you have provides :products , but for all pathom knows there is no relation between :product/id and :product/slug (Other than them both being present in :products). They could be completely random data, or magic labels, or whatever.

Excellent, thanks.