I’ve run into some unexpected behaviour around optionality in general. Not with batch resolvers however. Pathom3 seems to treat missing data as an error. Which I think is counter-intuitive in situations where there are multiple paths. For example a resolver might attempt to fetch data from a database, and then fall-back to a default value when the db doesn’t have anything. In this case, it would be expected behaviour for the db resolver to be missing data. I’ve had to implement a plugin that silences missing-data errors. Also, while I don’t use lenient mode, I do debug with it sometimes. And I have seen errors returned from intermediary attributes for paths that were unable to fulfil and request and superseded by another one that could. These errors were also unexpected because I didn’t ask for this intermediary attribute and my request was ultimately fulfilled with the alternative path. Essentially, I would get an error in my result with lenient mode but no errors at all with strict mode.

hello folks, yeah, sometimes it gets tricky, but in the sense of missing is an error, it should only get the error if there is a required thing and it exausted all the options to get it. @U03K8V573EC I need repro so we can investage the case in question, to see if its a pathom bug or some setup issue

@U3XCG2GBZ if you send situations like these when you encounter, would be good to chase down possible errors in the processing with optionals

@wilkerlucio thanks, I'll work on a repro, I've noticed that there might be a few issues related to nested inputs in the batch resolution. the parallel parser was working in my example but was 20 times slower making it unusable as a workaround

thanks! I'll have a look later today

I did some investigation, the issue only happens in lenient mode, and doesn't need batch at all, I got down to this repro:

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

(pco/defresolver book [_]
  {::pco/input  [:book/id]
   ::pco/output [:book/name]}
  {})

(pco/defresolver item [_]
  {::pco/input [:item/id]
   ::pco/output [:item/id :book/id]}
  {})

(def env
  (-> {:com.wsscode.pathom3.error/lenient-mode? true}
      (pci/register
        [book
         item])))

(comment
  (p.eql/process env
    {:item/id 1}
    [:item/id
     :book/name]))

I'm considering just removing it altogether, there are ways to pull out this information from node stats if wanted, so this part of the process can be simplified

I'll give some though to it and continue tomorrow

@wilkerlucio are you referring to “missing attribute” error or lenient mode as the removable feature?

I think you mean the missing attribute error and if so, I agree. If an attribute is optional or available from multiple paths, it would be intentional to have a resolver be unable to provide it.

I'm referring specifically to the error Insufficient data calling resolver

lenient mode is an important feature, no intention to remove it whatsoever 🙂

and to be clear, the Insufficient data calling resolver is a debug optimization, to help point where in the chain the output was missed, but other than that it doesn't really affects how the runner works

removing sounds fine to me my main issue was that I have a wrap-on-resolver-error that logs errors, and usually those are important but here its just logging infinite amounts of things that are not errors additionally there isn't enough information in the error Insufficient data calling resolver to filter it, might be worth adding to ex-data so one can filter without diving into the ex-message and string processing. Eg resolver-name and missing-attribute should def be in there

I'm very much leaning on removing it, in hindsight the implementation of the idea is bad, I think the optional case demonstrates it clearly

works for me, then I can remove the code I have to mute the errors in that plugin

^ I also muted this error

fixed on main

please let me know if that fixed your cases

@wilkerlucio I still get a lot of {:response "Insufficient data calling resolver 'question.drag-order/answers-resolver. Missing attrs :question.drag-order/id"}

my bad I forgot that I'm overwritting deps locally, after pulling latest pathom3 main no more errors