executeAsync should throw errors

[anarkrypto]

It is intuitively expected that executeAsync will throw an error rather than resolving the promise with a { serverError: "message" } object.

Without rejection, the implementation with libs like react-hook-form does not produce the expected effects, as formState.isSubmitSuccessful will always be true even if it is not successful.

Consider react-query's mutateAsync:

Use mutateAsync instead of mutate to get a promise which will resolve on success or throw on an error.
This can for example be used to compose side effects.

https://tanstack.com/query/v4/docs/framework/react/guides/mutations#promises

[TheEdoRan]

Hmm, I understand your point, but calling the action directly doesn't throw errors either. Right now you can set throwValidationErrors and throw server errors inside handleReturnedServerError at the client level, and/or use throwValidationErrors and throwServerError at the action level to throw errors.

Then, for instance, how would you handle validation errors when using executeAsync? Would it be better to throw them like you suggest with server errors or return them (current implementation)?

[anarkrypto]

calling the action directly doesn't throw errors either.

Of course, using react actions has numerous limitations. That's why we use next-safe-action.

Then, for instance, how would you handle validation errors when using executeAsync? Would it be better to throw them like you suggest with server errors or return them (current implementation)?

I prefer to use onError callback. However executeAsync could return a custom extended Error just like zod does.

Right now you can set throwValidationErrors and throw server errors inside handleReturnedServerError at the client level, and/or use throwValidationErrors and throwServerError at the action level to throw errors.

Great, throw server errors inside handleReturnedServerError at the client level solves the problem.

I believe the question now is whether it is worth making this a standard behavior in next-safe-action. I believe it would be more intuitive.

[TheEdoRan]

@anarkrypto Same Next.js version as before? Can you please provide a reproduction link? Thanks.

[anarkrypto]

@TheEdoRan, not the same version, I am currently using the lastest next version. Do you think something changed in next to produce this? It's not the fact that handleReturnedServerError was run on the client side while handleServerError is on the server?

I do not have a minimal reproduction yet, but you can test it here: https://nanopayme-git-main-nanopay.vercel.app/login
Try to login with a fake credential. As you see, since I am throwing at server side, vercel does not return any message.

Here is the code: https://github.com/nanopay/nanopay.me/blob/bd780bcf8f2a1d2c6d23d886febe30ab1bbd5bba/src/lib/safe-action.ts#L5-L13

[TheEdoRan]

not the same version, I am currently using the lastest next version.

If you updated packages outside of this library, the issue could be related to them. To find out what's causing problems, try to downgrade the other packages to their previous versions and see if the issue persists.

It's not the fact that handleReturnedServerError was run on the client side while handleServerError is on the server?

handleReturnedServerError -> handleServerError. I've just updated the name, same functionality as before, always ran on the server, no difference!

I've just tried to throw the error inside handleServerError in the playground app of this repo and it works fine. Not sure if something changed with the latest Next.js versions, if you find the time please provide a minimal reproduction, thanks.

[anarkrypto]

@TheEdoRan here is a minimal reproduction test with next v14.2.14

Repo: https://github.com/anarkrypto/next-safe-action-cannot-throw
Demo: https://next-safe-action-cannot-throw.vercel.app

As you see, the error is only returned when the handleServerError return as a string, instead throw.
When we throw inside the server, next.js does not return a body.

[TheEdoRan]

@anarkrypto I've just tested your repro, it seems to work fine on my end. When I click on "throw error B" it throws the error correctly, and this gets logged in browser console:

Unless I'm missing something, I don't see where the bug is.