What imostly want is to avoid spewing the :com.wsscode.pathom3.entity-tree/entity-tree in the response when the exception is Unauthorized

This is interesting. It would be useful to wire many graphs together with their own configurations. For example running in parallel seems to be all of nothing.

yes the idea is to drop the query entirely in case of unauthorized access to an attribute for now if there's a way to just drop the subquery I'd probably go for it, but one step at a time, and it might not be easy because the authorization attributes are siblings of the others

I was initially going for a solution that rewrites resolvers to include authorization attributes in the inputs (and a pending-authorization / authorized resolver for circular dependencies eg child must have parent authorized but you only know the parent after resolving the child) but it turned out to be too slow when dealing with 1000s of attributes whose authorization requires deep recursion. I am now following the path of changing the query which drastically improved the perf in my case https://github.com/yenda/pathauth It would be very close to no-auth perfs once I let parent authorization flow to children

this goes a bit against the processing model of Pathom, because pathom intentionally doesn't have anything to deal with entities per-see, because for Pathom entities are just generic bags, so from an authorization perspective, just because you can't access attribute :a, that doesn't mean you wont be able to access :b at the same entity, in this thinking, each attribute has potently its own authorization behavior

yes that's a trade-off I'm fine with here. I expect access to unauthorized attributes to be an adversarial use case. No user (UI) would do that

in return I get the advantage that pathom can resolve my authorizations and fail early when its not granted

@U066U8JQJ > this goes a bit against the processing model of Pathom, because pathom intentionally doesn't have anything to deal with entities per-see, because for Pathom entities are just generic bags, so from an authorization perspective, just because you can't access attribute :a, that doesn't mean you wont be able to access :b at the same entity, in this thinking, each attribute has potently its own authorization behavior I agree with this, that's why ideally the behavior I'd be looking for is that when an authorization resolver throws, I have the list of siblings that need to be blocked. But it also means I need to be able to interrupt the subqueries if those siblings are joins. For now it's not too much of a big deal because I'm fine with throwing away the whole query

but it's too good right now to be able to define authorization like this:

(defattr id :question/id :int
  {...
   pa/auth [:course/authorized?]})

i.e. having a single mutation for entire project.

other option is (org.myproject.user/crud ...) in the same ns as all the other user code. This way I can put code in specific to the user...

third option is (org.myproject.user/delete ...), (org.myproject.user/create )...

I like first one, because I can make a lot of use of multimethods and specifically keyword https://clojuredocs.org/clojure.core/derive (which seem cool, but I havent used them before). Any thoughts?

in general I rather have one mutation per operation, not a rule though, but you can also make some helpers that generate resolvers (to avoid the repetition)