Why does this happen in Pathom3?

(pco/defresolver foobar []
  {::pco/output [:id :name]}
  {:id 1 :name "foobar"})

((p.eql/boundary-interface
   (pci/register [foobar]))
 {:pathom/eql [:id :name] :pathom/entity {:id 0}})

=> {:id 0, :name "foobar"}

I was writing a test and was not expecting this behaviour. I feel like it could introduce bugs where the wrong resource is returned but it looks good because the id matches now

@caleb.macdonaldblack this happens because your resolver doesn't require any input, so this makes :id and :name available globaly

so what pathom sees is that you have already an id (wiht value 0), and the missing name sees a resolver that requires no input, so it pulls from that, makes sense?

(it also works the same in Pathom 2)

I removed the input to simplify but it’s the same behaviour with an input

(pco/defresolver foobar [{:keys [id]}]
  {::pco/output [:id :name]}
  {:id 1 :name "foobar"})

((p.eql/boundary-interface
   (pci/register [foobar]))
 {:pathom/eql [:id :name] :pathom/entity {:id 0}})

=> {:id 0, :name "foobar"}

same thing, in this case, :name is missing, so it uses the ID, given the output is fixed, it fills the missing parts

but pathom wont ever override values already present

so you had :id 0 from start, Pathom will never change the data, that's why you see what looks inconsistent, but in this case I think we can argue that the resolver is returning something inconsistent based on the id

Yeah I agree the resolver is bad. If there was a bug with the resolver where the input isn’t used, it could be combined with irrelevant output and wouldn’t be obvious. This happened when I was writing a test

It’s nothing major, I was more curious if anything

sure, no problem, its good to clarify the intentions 👍

but I hope the process makes sense, if Pathom did override data it would be madness 😛

Actually that does make sense now

Imagine that haha

there is one idea though, that I think would be useful as a developer tool, is some plugins to validate output

so in a case like this, pathom could see a resolver trying to modify some already present data, anda this is a strong indication that something is flawed in the logic of the resolvers

and notify the user in some way, or even break

Ah yeah, that would’ve been a good indicator for me. I can’t imagine this happens often though.

yeah, the idea is to be some kind of linter thing, another thing I would like to catch for example, is if the output contains more keys than expressed in ::pco/output, this is a strong indicator that the output definition is incomplete

not my priority to make this, but if anything would want to give it a try, the code could be later integrated as a built-in plugin

I'm starting to use caching in Pathom3. The API is very easy to integrate, so thanks! One oddity: From what I understand, resolvers require caches to support protocol pcache/CacheStore but the plan cache does not. The plan cache assumes a cache atom from clojure.core.cache . Does it make sense for the plan cache to support the protocol? I think that would mildly simplify the API

@markaddleman core.cached is a separate library, and it doesn't work on CLJS for example, so I dont plan to integrate directly with that (altough there are code examples on how to integrate with it)

Pathom extends atoms and volatiles to implement pcache/CacheStore protocol, and that's whats used by default everywhere

In the latest alpha, I think Pathom specs require that the plan cache be an atom. I supplied a pcache/CacheStore record to it and Pathom got very upset

repro demo?

Sure, one sec

Pathom with guardrails enabled reports a lot of spec failures

oh, right, the specs, yeah, I can see the spec is wrong, I can fix it later today, thanks for the report