I need to investigate that, can you open an issue on pathom3-graphql repo to keep it tracked?

@U066U8JQJ sure thing. I'll just copy the above over into there. Thank you 🙏

Thanks so much, @U066U8JQJ, for maintaining and documenting such a fantastic library. We’re about to go live with a Pathom3 implementation, and we’ve really loved it.

To clarify, the resolver with ::pco/priority returns nil so I expected the resolver without ::pco/priority to be invoked

Actually, I got this backwards: The resolver without ::pco/priority is always invoked while the resolver with ::pco/priority is not invoked

hello mark, can you make a repro example please?

Sure

I tried to reproduce with this:

(ns com.wsscode.pathom3.demos.repro-priority
  (:require [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.interface.eql :as p.eql]))

(pco/defresolver a1 []
  {:a 1})

(pco/defresolver a2 []
  {::pco/priority 1
   ::pco/output [:a]}
  nil)

(def env
  (pci/register [a1 a2]))

(comment
  (p.eql/process env [:a]))

but in this case I get the desired result, so I wonder what kind of edge case you may have hit

I'll try to reproduce this weekend

I can't reproduce. 😕 If I run into it again, I'll be sure to create a repro case before I forget all the context

no worries, it will eventually bite back again

for a contexto to help debug: the main change in the algorithm is that the previous path would look at every node in the subpaths to find the highest priority, while this new one will look only at nodes that are responsible directly for the attribute that the OR node is looking for