I haven't look at this yet, but I am very interested in this too.

params is only used for mutations so you shouldn't specify that key. ::pco/input is what resolvers use and it is a vector of keywords (or maps if you wanted to specify nested inputs)

resolvers can get params too, the format is EQL, same as input and output, the description doesnt affect anything in terms of running, but can be used in the future to support tools like pathom viz

Oh that's right! I've used them with things like pagination for a resolver. Forgot about that.

(swap! (::pcr/resolver-cache* env)
       dissoc
       ['fully.qualified/op-name
        {:resolver/input true}
        {}])

where are you getting :resolver/input from? I assumed that would be the same input you destructure in the resolver, but the extra stuff going on in that function I linked gives me pause

:resolver/input is just an example of what the input map could be. If you had the following resolver

(ns my.namespace)

(pco/defresolver my-resolver
  [{input :my/input}]
  {:my/output (str "out: " input)})

(swap! (::pcr/resolver-cache* env)
        dissoc
        ['my.namespace/my-resolver
         {:my/input "foo"}
         {}])

it's not clear to me that

input-data      (pfsd/select-shape-filtering entity (pfsd/merge-shapes input optionals) input)         input-data      (pcr/enhance-dynamic-input r-config node input-data)

@U797MAJ8M do you want to do a precise invalidation (for one specific input/params set) or looking for to clear the cache for all entries for a specific resolver?

because if you are looking for the later, I suggest using a separete cache store for it (https://pathom3.wsscode.com/docs/cache#custom-cache-store-per-resolver), this will make trivial to clear the whole cache on that store (just reset it to {})

just remember that to make it work as the default cache store, you will also need a plugin to reset that store for each request, otherwise it will behave more like a durable store (in the sense it will live though multiple requests, instead of per request)

you can use this built-in plugin to help creating a new cache store for that name on each request: https://pathom3.wsscode.com/docs/built-in-plugins#extend-environment

another thing that you may find interesting, is the config ::pco/cache-key, you can use this to provide a function that generates the cache key for that resolver, instead of using the standard [op-name input params] form

the function on ::pco/cache-key will take [env input-data] as arguments

ah, cache-key is what I want, thanks

keep in mind that if you don't change the cache store, you are sharing it in a flat map with the cache of every other resolver, so make sure you are not doing anything that may conflict cache keys