Fork me on GitHub

Hi there, I’m using the parallel-parser on pathom 2.4.0. It seems that if one of my resolvers throws an exception it messes with the state-machine of the parallel-parser and from that point on - every 60 seconds (key-process-timeout), I’m getting a clojure.lang.ExceptionInfo: Parallel read timeout Anyone else experiencing this?


Here’s the relevant code:

(def eql-parser
  "Pathom EQL parser for Accounts.
  Keep public to allow access in dev mode, see user.clj."
   {::p/env                               {::p/reader               [p/map-reader
                                           ::p/placeholder-prefixes #{">"}}
    ::p/mutate                            pc/mutate-async
    ::p/plugins                           [(pc/connect-plugin {::pc/register registry})
                                           (p/env-plugin {::p/process-error (fn [env ex]
                                                                              (cast/with-context (select-keys env [:correlation-id])
                                                                                                 (cast/alert {:msg "PathomError Accounts"
                                                                                                              :ex  ex}))
                                                                              {::p/reader-error (.getMessage ex)})})
    ::parser/external-wait-ignore-timeout 10000              ;; the default 3000 is a bit problematic

(defn eql
  [env eql-query]
  (async/<!! (eql-parser env eql-query)))


hello, can you send a full repro? I don't see the resolvers in this example


Thanks for getting in touch Wilker. I’ll try to come up with a complete example. Do you see any issue with the error handler returning (::p/reader-error "…"} ?


no worries, and I dont see any immediate issue on that


suppose my query is this and I have exactly one resolver for each attr:

   {:B [:C]}]}]
if I change ::p/env in my resolver for :B, I should expect that these changes will be available for :C but that they may or may not be available for :A, right? (Since children have to be processed after parents, but sibling attrs may be processed in either order)


yeah, changing the resolvers in mid-process sounds a dangerous game to play


what are you trying to achive?


yeah 😅 well, long story short, I'm trying to resolve attrs (sometimes 3-4 joins deep) that need to be aware of a top-level ident join


Probably it's better to just write resolvers that express the whole path in ::pc/output and ::pc/input from the top-level ident to the attr instead of fiddling with the env, which is dangerous as you suggest


(tangentially, now I'm wondering if I understand something right--`::p/env` additions from a resolver do not persist beyond the lifetime of the mutation/query that it was made in, right? global pathom env != tx env)


correct, you can only affect env for children nodes, the initial motivation for it was to implement a sharding system, where some entities may change the shard they are (and that affects the children, because are related, and likely on the same shard)

🙌 1

you can also consider Union queries, which is made to support branching on the query (so use query A if entity is like X...), but for many levels deeper it may not be so easy


hm ok yes, I'll consider whether unions might be a good fit. Thanks for the help as always 🙂