Clojurians Log v2

I have a question about error handling in Pathom. I'm using Pathom with the sha 304a6b3a56d588eab50f7f6eaf2c2c7b31750782 The code below returns the attribute errors as I would expect, but the same code returns an empty map when using the latest sha acf3134aa52668d83cffd326c46fca1ef0120e99.

(p.eql/process
    (-> (pci/register
          (pbir/constantly-fn-resolver :error-demo
            (fn [_] (throw (ex-info "Example Error" {})))))
      (p.plugin/register
        [pbip/remove-stats-plugin
         (pbip/attribute-errors-plugin)]))
    [:error-demo])
=> {:com.wsscode.pathom3.connect.runner/attribute-errors {:error-demo #error{:message "Example Error", :data {}}}} 

hello @fatihict, great to see you around again 🙂

I checked it out, and indeed it as a problem, you can fix it by removing the pbip/remove-stats-plugin

I'm thinking about some of the plugin architecture, I noticed later in the game a problem relateed to the idea I came up when combined with batch resolvers

that lead to a need to change the implementation of attribute-errors-plugin, and now I see the new way isn't compatible with remove-stats-plugin anymore

Hey Wilker 👋

Ah oke, that is good to know. Thanks for clarifying.

Hi, @wilkerlucio. I've been trying to use priority on the resolvers on Pathom3, and I have to be honest: I keep getting unpredictable results. I'll try to hack something to see if I can somewhat change the prioritization, and I know we already discussed this on https://github.com/wilkerlucio/pathom3/discussions/57 - I'm just giving some feedback on my feelings about this new feature 🙂

thanks, as we talked before, this still a first idea for it, glad that you are finding issues, can you add more details on the discussion? explain some case that doesn't work, so we can think about how we can make it better

Right, so the case I sent on the discussion was one example. What I find is that weights more in the prioritization is mostly resolved on intermediate steps to get to the goal. So sometimes you ask for :a, and :a is reachable both from a "2" and "1" priority, but what weights more are intermediate steps that may not exist on both graphs on the path to get :a

(I don't know if my last explanation made any sense 😄)

Also, another question: is there a way (planned or not) to get, from a resolver, which attributes were asked on the query? I'm thinking about a resolver, for example, that outputs [:person/name :person/age :person/id] and can somehow issue a SQL query with only the attributes that the query asked...

this is a problem for dynamic resolvers, which is the thing I'm currently working on

Is there any documentation on how they will work in the future, or something? 🙂

not yet, but maybe you can work some partial thing with the current stuff

to answer your question more directly, inside env, if you get the ::pcp/node, inside of it there is ::pcp/expects, which is the attributes expected from the resolver

Also, one last question: When something fails, it shows some errors like:

:definition/contents
   {:com.wsscode.pathom3.error/error-type
    :com.wsscode.pathom3.error/node-errors,
    :com.wsscode.pathom3.error/node-error-details
    {3
     {:com.wsscode.pathom3.error/error-type
      :com.wsscode.pathom3.error/attribute-missing},
     4
     {:com.wsscode.pathom3.error/error-type
      :com.wsscode.pathom3.error/attribute-missing}}}},

Nice, will try it soon-ish 🙂