pathom

:pathom: https://github.com/wilkerlucio/pathom/ & https://pathom3.wsscode.com & https://roamresearch.com/#/app/wsscode
markaddleman 2021-03-15T18:32:41.016300Z

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?

wilkerlucio 2021-03-15T18:38:11.016900Z

have you considered having multiple resolvers for the tier?

markaddleman 2021-03-15T18:38:41.017800Z

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

wilkerlucio 2021-03-15T18:38:47.018200Z

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

wilkerlucio 2021-03-15T18:38:48.018500Z

yes

wilkerlucio 2021-03-15T18:39:25.019600Z

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

markaddleman 2021-03-15T18:39:26.019800Z

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

markaddleman 2021-03-15T18:40:43.020Z

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

markaddleman 2021-03-15T20:07:26.026200Z

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?

markaddleman 2021-03-16T15:44:14.012Z

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

markaddleman 2021-03-16T15:44:45.012200Z

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

markaddleman 2021-03-16T15:45:16.012400Z

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

markaddleman 2021-03-16T15:46:34.012600Z

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

wilkerlucio 2021-03-16T16:30:38.012800Z

@markaddleman 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

wilkerlucio 2021-03-16T16:31:03.013Z

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

wilkerlucio 2021-03-16T16:31:13.013200Z

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

markaddleman 2021-03-16T16:37:13.013400Z

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

wilkerlucio 2021-03-16T21:42:10.015Z

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

wilkerlucio 2021-03-16T21:43:33.015200Z

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)

wilkerlucio 2021-03-16T21:43:59.015400Z

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

markaddleman 2021-03-16T22:29:52.015600Z

that would be great

markaddleman 2021-03-22T01:38:18.012600Z

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

wilkerlucio 2021-03-15T20:08:36.026300Z

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

wilkerlucio 2021-03-15T20:09:28.026500Z

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)

wilkerlucio 2021-03-15T20:09:43.026700Z

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

markaddleman 2021-03-15T20:16:44.027Z

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