I have this exact problem when refreshing JWTs.

There are several parts that interact here. Unfortunately I never had the time to tune the template to be perfect on error handling, so it may be a bit out of whack (if that’s what you based on). The server response expected from the API is always a map, but an exception can cause that to not be true, which in turn can cause the response to NOT be encoded as transit+json. So, step 1 is to ensure that your server is always returning transit+json responses, OR you have to deal with it in the next layer (the http remote in the client). The client remote gets the raw response. For some server errors it is impossible to actually have it be transit encoded, and you just have to do something else. This is where the response middleware comes into play. It is the layer the decodes the transit and has expectations about the response content. What you do with errors in you app can be tuned here as well. For example you could pop up UI toasts or even have an atom holding the Fulcro app that allows you to transact something as you circumvent the response decoding.

Shameless self - plug https://blog.jakubholy.net/2020/error-handling-in-fulcro/

Hi Tony and Jakub, Thanks both very much for your replies, much appreciated. To your point, Tony... > So, step 1 is to ensure that your server is always returning transit+json responses The bit of code that's returning a String under error circumstances is within Fulcro (as I mentioned above - com.fulcrologic.fulcro.server.api-middleware/handle-api-request). As I said if I modify that to return a map (with the error message in it) that does fix the problem. It's not worth updating that function to return a map, is it? Or do we need to be mindful of changing the behaviour and therefore it's better not to change it? If that's the case would another fn be worth adding and deprecating the old one? I'm happy to create a PR if you think that's useful, but obivoiulsy just say if not (I can just create a version locally for our needs, no problem) Thanks again both for your help!

Ah, hm. Yes, that is a bit of an oversight on my part, but it has been that way for a long time, so it is possible someone’s network stack relies on it. Thus, changing it would be a breaking change. The options are: 1. Create a handle-api-request2 that returns a map 2. Make the current one more configurable somehow 3. Do nothing and let others fix it as they see fit

How about adding an arity. The new argument would be a function that transforms exceptions into responses. That would be a non-breaking change, and would let you configure it as you see fit.

If you’re interested in doing that PR, updating the docstring, and updating the relevant section of the dev guide it would be much appreciated.

Great - an extra arg sounds like a good idea, thanks. I'll create a PR with all the associated bits, no worries. Might take a day or two to get to it, but that would be nice to do. Cheers :)

cool, thanks