pathom 2021-03-15 | Slack Archive

markaddleman18:03:41

Wondering what people's thoughts are on parameter value-driven dispatch for resolvers. Here's my use case: I have some resolvers that compute the same schema output but the particular logic depends on an incoming parameter. For example, I need to compute :customer/invoice but the logic for computing the invoice depends on :customer/tier. This wouldn't be much a problem problem except that platinum tier customers need different inputs than gold tier. My naive approach is to have a single resolver with input of :customer/tier and a confusing union of the inputs required for both platinum and gold tiers. Is there a better way of structuring the code?

wilkerlucio18:03:11

have you considered having multiple resolvers for the tier?

markaddleman18:03:41

Each resolver would return nil if it didn't apply?

wilkerlucio18:03:47

if a resolver fails (by exception, or missing some parts of the data) pathom tries another one

wilkerlucio18:03:48

yes

wilkerlucio18:03:25

and you can use resolver prioritization to force some to go first (in case it matters)

markaddleman18:03:26

I thought about it as I was typing up my question 🙂 but I was too lazy to try it out.

markaddleman18:03:43

Yeah, I think that will work. Conceptually, it seems somehow cleaner to have this logic as part of the {::pco/input ..., ::pco/output ...} declaration but the approach you suggest will get the job done

markaddleman20:03:26

With guardrails turned on, I am getting the following error:

Execution error (ExceptionInfo) at com.fulcrologic.guardrails.core/run-check$fn (core.cljc:76).

com/wsscode/pathom3/connect/planner.cljc:1279 first-common-ancestor's return type
-- Spec failed --------------------

  nil

should satisfy

  pos-int?

-- Relevant specs -------

:com.wsscode.pathom3.connect.planner/node-id:
  clojure.core/pos-int?

-------------------------
Detected 1 error

Without guardrails, I get the following:

Execution error (AssertionError) at com.wsscode.pathom3.connect.planner/merge-missing-chain (planner.cljc:1428).
Assert failed: Error finding ancestor during missing chain computation
ancestor

(plus large stacktrace) Unfortunately, this happens during planning so pathom-viz doesn't show anything interesting. I have isolated the problem down to one resolver and one of its two inputs. If I include the input, I get this error. If I exclude it, the plan is computed without a problem. If I mark the attribute as optional, it also fails. There are probably two (maybe three) resolvers capable of producing this attribute for the given query - but I don't think that's particularly out of the ordinary. At present, I have a fairly large number of resolvers and I'm not sure how to narrow down the problem to create a reproducible case. Any suggestions?

wilkerlucio20:03:36

this is likely a bug, this is one part of the planning process that tries to find a common node when something depends on things that are spread across the graph

wilkerlucio20:03:28

one thing you could use is the planner debugger, which goes step by step, its currently broken on the website, but that's something I'll get fixed later today (the UI's on the planner page)

wilkerlucio20:03:43

once working, you should be able to use this: https://pathom3.wsscode.com/docs/planner/#explorer

markaddleman20:03:44

wonderful. Can you ping me when you have the ui fixed? I'll hop on it and get you the results

wilkerlucio06:03:07

@U2845S9KL fixed for viz elements just pushed up

markaddleman15:03:14

Hi - I loaded up my OIR index and my query into the tool. I'm not really sure what I'm looking at.

markaddleman15:03:45

When I execute the failing query, I get an indication that the final node is unreachable.

markaddleman15:03:16

However, when I change the query to return the problematic attribute, it computes the plan just fine and returns the correct result

markaddleman15:03:34

Should the "Log Graph" button do something? When I click it, the console displays a (presumably ClojureScript) object but it does not look intelligible

wilkerlucio16:03:38

@U2845S9KL can you check if you are in pathom latest? because the viz uses its own compiled version of pathom to compute the plan there, I wonder if you missing some fix

wilkerlucio16:03:03

the log graph, yeah, was a oversight, because in dev logs fine, but on the site its not usable

wilkerlucio16:03:13

I can fix that to log a pr-str of the graph

markaddleman16:03:13

I'm using pathom commit 6b2282e6dc4cfabd449cf7837fcefdd1c9b09891 . I'm not sure how to get the version of Pathom Viz but I'm almost certain it's the latest compiled binary from github. btw, the exception that I'm getting is from Pathom, not Viz

wilkerlucio21:03:10

ok, I think its time to get the stepper to the next level

wilkerlucio21:03:33

currently using that view from embed has an issue, actually more than one: 1. it runs using the internal pathom, not the client pathom, and that can cause confusion 2. this version only looks at index-oir, which is not complete, it don't contemplate the nested queries (and I believe that may be the case you are hitting)

wilkerlucio21:03:59

the next level is to integrate that properly in Pathom Viz, some sort of button to debug a query, that can leverage all index, and run in your environment

markaddleman22:03:52

that would be great

markaddleman01:03:18

fwiw, I can't reproduce my original problem. The structure of my resolvers has changed a bit since I last saw the problem. I'll keep an eye out

2021-03-15

Channels