@wilkerlucio yes the key is there

https://lh3.googleusercontent.com/-1IihqiOrKVg/W9UHFaDZRYI/AAAAAAAAGHM/p9X0v1J7MWQuTzVqqSHb2vEKY609Kkv0ACLcBGAs/s0/Screen%2BShot%2B2018-10-27%2Bat%2B5.46.59%2BPM.png

@currentoor then you must check on the fulcro side of things, if the remote is getting the data the job is done in pathom side

I see your key on the map is another map, is that expected?

feels like it should have just the id there (not a map with id in it)

yeah that’s the weird part

seems like it looses it’s tempid encoding

i believe tempids under the hood are encoded like that

you should check your transit configuration, you need to support tempids there

the fulcro default one usually works, but you also have to check your server side

yeah weird stuff, well thanks for the help

at least we know pathom is doing what its supposed to

yup 🙂

but one thing to note is this was working before we moved the parser to pathom

you just changed the parser? you can try checking the types in an out before encoding, might tell something

I gotta go now, but let me know if you figure more out

no worries

is there a way to make exception bubble up to the client?

i was relying on mutations throwing exceptions when something goes wrong

for example i do authorization check and throw an exception if permissions are not valid

@currentoor the error plugin is there to prevent that, you can use the flag ::p/fail-fast? true to force it bubble, but I suggest you also consider another approach, what I usually do is return a map with some special key like ::p/errors that tells me that request failed

this way I can handle it on the client like any other data

but if you really want to keep mutations blowing, you can just modify the error-handler-plugin, if you look at its definition this is what you will find:

(def error-handler-plugin
  {::wrap-read   wrap-handle-exception
   ::wrap-parser wrap-parser-exception
   ::wrap-mutate wrap-mutate-handle-exception})

so you can dissoc the ::wrap-mutate to remove the error catcher from mutations only

like: ::p/plugins [(dissoc p/error-handler-plugin ::p/wrap-mutate)]

thanks @wilkerlucio, i’ll try the other approach you recommend

So using the default error handler plugin, now i’m getting the response back as {:com.wsscode.pathom.core/reader-error "class clojure.lang.ExceptionInfo: Unauthorized Request..."}

which is nicer, but how do I change the key that the error is on?

i know there is ::p/process-error but that seems like it’s only for changing the value of the error, not the key

oh wait never mind, it actually let’s you specify the whole map

that might work

yeha, process-error is the way to go to give a custom handling 😉

so one other thing i want is to change the status of the response to show an error

that happens one level up from where process-error is being called

any parser magic to do that?

because if i put :status 401 in the result of process-error it puts it in the body of the response

yeah, that's by design to separate the error data from the response data, there is no way to change the up map, but in your UI you can instead render the ::p/reader-error map as the error data

or there is something that makes this pulling a problem in your scenario?

well fulcro-websockets has a global-error-callback

i was using that to log errors and redirect to login (if the status was a 401) or show some other error message

the UI render ::p/reader-error works only for errors related to what is being rendered

but if an auth token is expired i’d like to show a top level error then redirect to re-login

unless i’m mistaken about something

are you using the pessimist mutations from fulcro incubator?

in some places yes

but not for everything

because thats a good case for it, since it provides the error-action you can use that to handle any redirect concerns

yes it works for that, but i don’t always want to use pmutate!

for one it can only do one mutation not a sequence

I'm looking at the error handler code, I might be able to make it return the full error map, this would make it more extensible, I'm thinking that it actually doesn't even work to the fulcro incubator case now

because it always use the pathom reader error key

we can do sending some env flag like ::p/wrap-error? false so you get the full map control without breaking the previous behavior

@currentoor you think that works?

what if we had a different key instead? env flag like that seems finicky

::p/process-error-response for when you want to augment the whole response?

rather that just the error

I like the idea, not the name, maybe ::p/process-error2, I still feel like the whole response should be the one to start with

maybe ::p/process-error*

What do you mean “the whole response should be the one to start with”?

I mean to return the whole map instead of a nested key

What about::p/process-response-error

?

That seems like a more descriptive name

Oh sorry I mean process-response-on-error

that can work, can you open an issue please?

oh, wait

I'm double checking now, I think if you do the process error you get the whole map control don't you?

so you mean in the case you want that error in the response root?

yes

it looks like i can add a mutate-wrapper that does that right?

that's kind a leaky abstraction, what if you send 2 mutations and each get a different error status?

why would each get a different error status?

2 different requests

so seems like what you want is some more in the area of a global flags for general errors, is that correct?

i’m not sure i understand what you mean

i just want errors to have a non 200 status

preferably i can set the status depending on the error

I'm trying to understand that you want to do global app handling of those errors instead of localized handling

do you have some function in your control that wraps the http calls your api makes?

basically i’m looking for error behavior of the base fulcro mutation parser, but now i’m starting to think that goes agains the design philosophy of pathom

like ring middleware? yes, but most of my mutations happen over websockets

well, it's all doable, it's make to be flexible, but I like to discourage because in principle the API tries to encourage a path with good fault tolerance, in the moment you make some information about a particular error leaks to the global response context, this kind hurts the principle, but at same time I always try to make it as flexible as possible, so I make it hard but still make it possible, so you can do it at your own risk 😉

so, I was thinking you can write a simple plugin that wraps the parser and injects the http status in case something happens, you can control this state using an atom, here is an example:

is there a way to wrap the response, like ring middleware?

(def http-global-status-plugin
  {::p/wrap-parser
   (fn [parser]
     (fn [env tx]
       (let [status-atom (atom nil)
             result (parser (assoc env ::http-status status-atom) tx)]
         (cond-> result
           @status-atom (assoc :http-status @status-atom)))))})

yeah, wrap-parser wraps the whole thing

so in this case, you can then add some try-catch in a middlewere of your websocket call, and if it fails it can update this atom from the env so the status will be injected in the root

i see, so is it a bad idea if i just used p/post-process-parser-plugin to change the out going response on error

as a last plugin

right now it gets as input

#:ucv.ui.mobile-pos.screens.camera{new-wash-&-unconfirmed-vehicle
                                   {:error "Unauthorized Request",
                                    :fulcro.incubator.pessimistic-mutations/mutation-errors
                                    "Unauthorized Request",
                                    :status 401,
                                    :body
                                    {:message
                                     "mutation ucv.ui.mobile-pos.screens.camera/new-wash-&-unconfirmed-vehicle unauthorized, s.policy/fail violated"}}}

you could also write this as a plugin on the client side

you could wrap the network (pathom has helpers to make that easy) and just look at the mutations in the response (look for symbols at the response root)

and then you could pull the status from then, and at this point you have all the information (all the statuses) so you could take a decision to pick one in case of ambiguity

https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/fulcro/network.cljs#L122-L147

yeah that could work too

thanks

you'r welcome