I am getting an error from a missing mutation:

#:integration{retract "class clojure.lang.ExceptionInfo: Mutation not found - {:mutation integration/retract}"}

Actually there doesn't seem to be an error key for this?

(def example-parser
    (p/parser
      {::p/env     {::p/reader               [p/map-reader
                                              pc/reader2
                                              pc/open-ident-reader
                                              p/env-placeholder-reader]
                    ::p/placeholder-prefixes #{">"}}
       ::p/mutate  pc/mutate
       ::p/plugins [(pc/connect-plugin {::pc/register []})
                    p/error-handler-plugin
                    ;; removes ::p/not-found from outputs
                    (p/post-process-parser-plugin p/elide-not-found)
                    p/request-cache-plugin
                    p/trace-plugin]}))

(example-parser {} `[(foo/bar {})])
#:foo{bar #:com.wsscode.pathom.core{:reader-error "class clojure.lang.ExceptionInfo: Mutation not found - {:mutation foo/bar}"}}

What is the first arg to ::p/process-error fn?

Yeah, when a mutation throws an exception, no ::p/errors key is attached to the return.

@kenny hello, this code is the full example? the mutation seems to be really missing there, also I'm not seeing a configuration for the ::p/process-error

what you are seeing is just the default error implementation

altough is not the best, I don't wanna change because that would mean break the interface for current users that for any reasons didn't need to change it

@wilkerlucio Yes this is the full example. When an error occurs with a non-mutation resolver, you get the ::p/errors get on the top level map. This lets higher level code decide what to do with the response (e.g. if an error occurred perhaps send a 500 HTTP response to the client).

@kenny this goes a bit against the idea of soft fails, Pathom embraces that if one thing fail, others can still succeed, so we don't encourage this, but if you think makes sense for you, you can do via plugin, you can detect mutations (symbols in the root map) and check on that as well (that + root), makes sense?

@wilkerlucio I suppose I could do that. The asymmetry here is a bit confusing though. For example:

(pc/defmutation example-mutation
  [_ _]
  {::pc/sym    'example
   ::pc/input  []
   ::pc/output []}
  (throw (ex-info "uh oh" {})))

(pc/defresolver example-resolver-throwing
  [_ _]
  {::pc/output [:foo]}
  (throw (ex-info "uh oh" {})))

(def example-parser
  (p/parser
    {::p/env     {::p/reader               [p/map-reader
                                            pc/reader2
                                            pc/open-ident-reader
                                            p/env-placeholder-reader]
                  ::p/placeholder-prefixes #{">"}}
     ::p/mutate  pc/mutate
     ::p/plugins [(pc/connect-plugin {::pc/register [example-mutation
                                                     example-resolver-throwing]})
                  p/error-handler-plugin
                  p/request-cache-plugin
                  p/trace-plugin]}))

(example-parser
    {}
    [:foo])
=> {:foo :com.wsscode.pathom.core/reader-error,
 :com.wsscode.pathom.core/errors {[:foo] "class clojure.lang.ExceptionInfo: uh oh - {}"}}

(example-parser
    {}
    '[(example {})])
=> {example #:com.wsscode.pathom.core{:reader-error "class clojure.lang.ExceptionInfo: uh oh - {}"}}

It's strange that both mutations and resolvers handle errors differently.

I would've expected the mutation call to attach ::p/errors just like the resolver call did.

@kenny yeah, I can understand the issue with the inconsistency there, to be honest, these days I do the opposite, I move the errors from the outside to the inside (makes much easier to report problems in the UI), pathom has a specific helper for that: https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/core.cljc#L825-L846

the reason this ended up happening was historical, I kind copy over what GraphQL did in terms of errors (having a separated branch)

but after experience doing it I feel like its better to have then in the same level they happen

It's definitely a bit strange because typically you want the HTTP status code to match what happened with request processing.

@wilkerlucio Is there a way to change the format of errors? e.g. I want them to be in a cognitect anomaly.

@kenny yes, use the ::p/process-error in your env

then you have full control about how they get exposed

Oh cool! Pathom won't care that I messed with those things?

https://wilkerlucio.github.io/pathom/v2/pathom/2.2.0/core/error-handling.html

no, that's expected

I mean, this how to format the error output, the position will remain

What is the first arg to ::p/process-error fn?