Fork me on GitHub

I pathom3 error handling is still undergoing active thought so I'll just through this out there: Using ::psm/error-mode-loud and guardrails enabled, if the smart map cannot compute the requested key, guardrails throws an unhelpful error. When guardrails is disabled, the smart map returns nil. I'd like to see a useful error message under the loud case regardless of whether guardrails is enabled or not.


in loud mode it should throw an exception in case something goes wrong, independent of guardrails


if you are seeing something different, is probably a bug, can you send a reproduction case?


for EQL mode there is a new plugin that I'm about to document, that exposes the errors on the data


It turns out this is a me problem and not a pathom problem. The smart map is working exactly as you describe


Well, I'm not longer sure this is a me problem 🙂


When guardrails is enabled, accessing :a/output from m results in an unhelpful guardrails exception.


when a->b's input is available, the result is what you'd expect


when guardrails is disabled and a->b's input is not available, the result is nil . I'm agnostic as to whether this is desired behavior or not.


just checked on it, that guardrails messages are not wanted, something is wrong inside, checking now


now there is a third type of error ::node-error-type-unreachable, which covers the case where Pathom can't find a path for some attribute


New page for Pathom 3 docs: built-in plugins 🎉 !

👍 2

it seems like attribute-errors-plugin causes a massive slowdown, from ￱￱55ms to ￱￱200ms on my api call


gonna check on that, how big are your queries?


@U797MAJ8M can you try again on master please? I made a change that will remove the checks when no errors happen, this should make the standard path (when no errors happen) to stay the same speed


@wilkerlucio: much better now, no apparent perf impact in repl


cool, being honest, you will probably see a bit more when some error happen, but at least will be only for the entries that have error


this cost comes from plan traversing to find the errors, the plugin will do it once for each attribute you requested, and in case of a no-error it has to traverse back until the root, so the cost will highly depend on the graph complexity


I think this can be optimized in the future to reduce the number of required lookups


Is there a recommended way to test pathom resolvers? I would prefer to not have to call my create function before each test of a resolver


👋 in pathom3 you can invoke your resolver as if it were a function. not sure if that works in pathom2 as well


@royalaid if you are in pathom2 you can call the resolver function from your tests like this:

((::pc/resolve your-resolver) context params)
in pathom3 you can call the resolver directly


not sure if that’s recommended way for pathom2 though 🙂 that’s how we do it.


can map data be combined with EQL idents I am trying to provide both in an eql query but it seems pathom is ignoring at least one of them


I ended up just putting the initial attributes into env and proxing them to params through a resolver


@wilkerlucio Will pathom3 implement parameters like :xform, :as, :default or it will be done only by external plugins?


not planned to do any of that, make your plugins

✔️ 1

could the notion of ::pc/mutation-join-global also be done by an external plugin?


for that there is a new key, the new key is called :com.wsscode.pathom3.format.eql/map-select-include, the attribute-errors-plugin does it:


ah, sorry, for mutations is different, but doable as well, if you make a mutation plugin you can do the same there


great! i will investigate. would there be interest in having a built-in plugin to support that old behavior? if i get a solution I can submit a PR if you’d like


only if the feature makes sense as new feature for Pathom 3, but not for compatibility. its on my plans to have yet another library, to make the porting easier, any things that are related mainly for porting should go there

👍 1