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?
have you considered having multiple resolvers for the tier?
Each resolver would return nil
if it didn't apply?
if a resolver fails (by exception, or missing some parts of the data) pathom tries another one
yes
and you can use resolver prioritization to force some to go first (in case it matters)
I thought about it as I was typing up my question 🙂 but I was too lazy to try it out.
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
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?Hi - I loaded up my OIR index and my query into the tool. I'm not really sure what I'm looking at.
When I execute the failing query, I get an indication that the final node is unreachable.
However, when I change the query to return the problematic attribute, it computes the plan just fine and returns the correct result
Should the "Log Graph" button do something? When I click it, the console displays a (presumably ClojureScript) object but it does not look intelligible
@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
the log graph, yeah, was a oversight, because in dev logs fine, but on the site its not usable
I can fix that to log a pr-str of the graph
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
ok, I think its time to get the stepper to the next level
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)
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
that would be great
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
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
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)
once working, you should be able to use this: https://pathom3.wsscode.com/docs/planner/#explorer
wonderful. Can you ping me when you have the ui fixed? I'll hop on it and get you the results