Error handling for Server Actions

[ma13gagan]

Hey 👋

How to handle errors in server actions and use those errors to show alerts/toast in UI? I looked into the examples provided in the docs, and they are directly throwing the error. But how can we use that error in UI?

[ma13gagan]

Similar to fail in Sveltekit and badRequest in Remix

[sam3d]

Edit (15th September 2023)

With #55399, this has now landed in Next.js with experimental_useFormState from react-dom.

It's still pretty rough around the edges (as is to be expected), but this is so exciting!

Here's a good example of usage: https://stackblitz.com/edit/vitejs-vite-qmhsah

🎉🎉

[karlhorky]

Looks like @delbaoliveira announced official docs updates that include a recommendation for using useFormState:

• https://twitter.com/delba_oliveira/status/1733169596491018269
• https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#server-side-validation-and-error-handling

app/actions.ts

'use server'
 
export async function createUser(prevState: any, formData: FormData) {
  // ...
  return {
    message: 'Please enter a valid email',
  }
}

app/ui/signup.tsx

'use client'
 
import { useFormState } from 'react-dom'
import { createUser } from '@/app/actions'
 
const initialState = {
  message: null,
}
 
export function Signup() {
  const [state, formAction] = useFormState(createUser, initialState)
 
  return (
    <form action={formAction}>
      <label htmlFor="email">Email</label>
      <input type="text" id="email" name="email" required />
      {/* ... */}
      <p aria-live="polite" className="sr-only">
        {state?.message}
      </p>
      <button>Sign up</button>
    </form>
  )
}

[dest1n1s]

Currently I use the following workarounds, which take advantage of useFormState and the formAction prop. It avoids turning the whole form into Client Component by defining a client side SubmitButton and using it to track the state of all actions and show the error messages.

submit-button.tsx

"use client";

import { FormAction, FormResult } from "@/types/form";
import { Button, ButtonProps } from "@nextui-org/react";
import { useEffect } from "react";
import { useFormState } from "react-dom";
import toast from "react-hot-toast";

export type SubmitButtonProps = Omit<ButtonProps, "formAction"> & {
  formAction: FormAction;
};

export const SubmitButton = ({ formAction: originalFormAction, ...props }: SubmitButtonProps) => {
  const [state, formAction] = useFormState<FormResult | null, FormData>(originalFormAction, null);
  useEffect(() => {
    if (state) {
      if (state.type === "success") {
        toast.success(state.message);
      } else if (state.type === "error") {
        toast.error(state.message);
      }
    }
  });
  return <Button {...props} formAction={formAction} />;
};

types/form.ts

export type FormResult = {
  type: "error" | "success";
  message: string;
};

export type FormAction = (
  prevState: FormResult | null,
  formData: FormData,
) => FormResult | Promise<FormResult>;

[karlhorky]

@rwieruch wrote about some Server Actions error handling patterns here:

• Exploring Next.js Forms with Server Actions https://www.robinwieruch.de/next-forms/

[ADTC]

Wow, this would have been insanely easy and simple solution:

// HYPOTHETICAL - Not real code.
throw new Error('what went wrong',
  { cause:
    { nextNoDigest: true, originalCause: /* any */ }
  }
);

// Or:

// HYPOTHETICAL - Not real code.
catch (error) {
  error.cause = { nextNoDigest: true, originalCause: error.cause };
  throw error;
}

And in Next.js production, if nextNoDigest is true, then don't create a digest. Just reset the cause and throw the (re-created) original error to the client. Don't need to care about "leaking potentially sensitive details" because it's now the responsibility of the developer to avoid doing so in any error with nextNoDigest set to true.

Also in development, apply digesting when nextNoDigest is absent to make the behavior reproducible and on-par with production, but attach original error as cause to the "digest" error so development frontend can still display Next error modal, but the app itself sees the digest.

It would have been so simple to implement. Why are we having to go through the loophole of a success response to emit errors when we can just emit errors?!

[elie222]

Mentioned this here too: #66999

[arjunkomath]

@sam3d sorry, I'm still confused though, how we present the error to the user? we don't have useState in RSC to set the error and present that to the user? I couldn't find any examples in Next.js doc also.

[sam3d]

You can't get the return value of a server action in a server component yet. The action must be called from a client component to do this. We're waiting for this something like useActionState(action).

there’s a missing primitive on the React side needed to make that work with PE which hasn’t been implemented yet

https://twitter.com/dan_abramov/status/1655667749887025161

there would be a built-in API for tracking the last result of an action. like

const actionState = useActionState(action)

this built-in would work with PE. during submit we would “remember” which action was just submitted and what its result was. then in the SSR pass, prefill it

https://twitter.com/dan_abramov/status/1654482455267536896

[arjunkomath]

Got it. Thanks.

[codinginflow]

You can't get the return value of a server action in a server component yet. The action must be called from a client component to do this. We're waiting for this something like useActionState(action).

On the client, do I just wrap the server action call into try/catch?

[tubbo]

Would be neat if useFormStatus() could be used for this, somehow. It already allows for returning other things in the state, so it could be upgraded to e.g.

const { pending, response, error } = useFormStatus(action)

where response is the (serialized) object returned from the server action, and error is what you get back if the action throws an error (it would be a serialized Error instance).

You could use it in a generic <Form /> component like so:

import { useEffect } from 'react'
import { useFormStatus } from 'react-dom'
import { toast } from 'react-hot-toast'

export function Form({ loading, submit = 'Send', action, children, ...props }) {
  const { pending, response, error } = useFormStatus(action)

  useEffect(() => {
    if (pending) toast.loading(loading)
    if (error) toast.error(error.message)
    if (response) toast.success(response.message)
  }, [pending, response, error, loading])

  return (
    <form {...props} action={action}>
      {children}
      <button aria-busy={pending}>{submit}</button>
    </form>
  )
}

[sam3d]

https://twitter.com/dan_abramov/status/1655763129106587648

understanding this lets us have these other Hooks like useAction (name TBD) for tracking last result (which would work with PE), useFormStatus for tracking closest <form>’s pending status, etc. it lets us layer useful features that take advantage of both React and web equally.

[karlhorky]

Seems like this upcoming hook may be called useFormState:

• https://twitter.com/karlhorky/status/1700856655959773236
• https://twitter.com/karlhorky/status/1700855543311511708

[henninghall]

@ma13gagan @sam3d @ma13gagan

Until react has a built-in hook you can use this one. I just created it so please let me know what you think! ☺️
https://github.com/henninghall/use-action-state

const [run, { error, loading }] = useActionState(action);

Note that it is only for client side.

[lipp]

IMHO server actions feel pretty incomplete when there is no built-in (server-supported) way to "return" a response for:

• "ok"
• input validation feedback
• unexpected errors / exception

When there is no other visual confirmation of your action being dispatched successfully, this is really important I think.

I could think of an API which works for server and client components alike, which uses the form.name to make the connection between (potentially) multiple forms on the same page:

function Comp() {
  const formName = 'some-form'
  const {error, result} = getActionResponse(formName)
  if (error) {
     return <p>Oops</p>
  }
  if (result) {
     return <p>Done</p>
  }
  return <form action={...} name={formName}>...</form>
}

The getActionResponse should be available everywhere in the React Tree for easy integration of "global" feedback comps like toast / snackbar etc..

[MustafaWael]

I have also faced this issue when trying to build a login form. When the user submits the data, I need to inform them about the server response if the "email" or "password" do not match.

I spent some time tackling this problem, and here is the solution.

this solution also works when the javascript is disabled in the browser.

I created a class that manipulates the server response like this:

class AtomicState {
  constructor(public message: string | undefined = undefined) {}

  setMessage(message: string) {
    this.message = message;
  }

  getMessage() {
    const message = this.message;
    this.message = undefined;
    return message;
  }
}

This class is responsible for setting and getting response messages. The message property is initially set to undefined. The setMessage method sets the message property, and the getMessage method saves the current value of the message property in the message variable, sets it to undefined again, and returns the value of the message variable.

I can use this class as follows:

const state = new AtomicState();

and this the my login server action:

const login = async (formData: FormData) => {
  "use server";
  const email = formData.get("email");
  const password = formData.get("password");

  const res = await fetch("http://localhost:4000/users/login", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email, password }),
  });
  const json = await res.json();

  if (res.ok) {
    state.setMessage("Successfully logged in");
    redirect("/chat");
  } else {
    state.setMessage(json.error);
    revalidatePath("/login");
  }
};

Using the revalidatePath function, NextJS will reload the page again with the new data.

According to the Official Page of NextJS, revalidatePath allows you to revalidate data associated with a specific path. This is useful for scenarios where you want to update your cached data without waiting for a revalidation period to expire.

You can access the data from the state and render it in the UI like this:

...
<h2>{state.getMessage()}</h2>
...

Here is the whole file:

import { revalidatePath } from "next/cache";
import { redirect } from "next/navigation";

class AtomicState {
  constructor(public message: string | undefined = undefined) {}

  setMessage(message: string) {
    this.message = message;
  }

  getMessage() {
    const message = this.message;
    this.message = undefined;
    return message;
  }
}

const state = new AtomicState();

const login = async (formData: FormData) => {
  "use server";
  const email = formData.get("email");
  const password = formData.get("password");

  const res = await fetch("http://localhost:4000/users/login", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email, password }),
  });
  const json = await res.json();

  console.log(json);

  if (res.ok) {
    state.setMessage("Successfully logged in");
    redirect("/chat");
  } else {
    state.setMessage(json.error);
    revalidatePath("/login");
  }
};

export default function Login() {
  return (
    <main className="min-h-screen bg-gray-100 grid place-content-center">
      <h1 className="text-center text-5xl mb-8">Login</h1>
      <h2>{state.getMessage()}</h2>
      <form
        className="flex flex-col gap-y-4 bg-gray-700 p-14 rounded-xl"
        action={login}
      >
        <div className="form-control">
          <label className="label" htmlFor="email">
            Email
          </label>
          <input
            className="input"
            id="email"
            type="email"
            placeholder="Email"
            name="email"
          />
        </div>

        <div className="form-control">
          <label className="label" htmlFor="password">
            Password
          </label>
          <input
            className="input"
            type="password"
            id="password"
            placeholder="Password"
            name="password"
          />
        </div>

        <button className="btn" type="submit">
          Login
        </button>
      </form>
    </main>
  );
}

[karlhorky]

Interesting approach, wonder what this would look like without using a class. Maybe there's a simpler pattern here somewhere...

Edit: Or I see @Dev-Siri posted an alternative using an object below

[Dev-Siri]

Following up @MustafaWael solution.
This works if everything is server component. But I was facing a problem because I needed to pass state to a client component (as it does some client-side validation with JS). This can also be represented as a plain object passed to client components which when revalidated works as expected.

For Server -> Client, create an object (not a class):

let signInState: SignInState = {
  confirmation: "",
  error: null,
};

Then I pass it to the client component:

<form action={passwordLessSignin}>
  <EmailSignIn state={signInState}  /> {/* Client Component */ }
</form>

The email sign in uses the state as usual, but I update it in the server action:

async function passwordLessSignin(formData: FormData) {
  "use server";
  const { res, serverError } = /* ... */;

  signInState = {
    confirmation: "Sent to email", /* res */
    error: null /* serverError */
   }

  revalidatePath("/"); // makes the new state show
}

This way it works even with the server-client gap.

[cevaris]

Hmm, can you please post a full example of the component?
For me, the non server part cannot find reference to signInState. i.e. Error: signInState is not defined.

The only way I got this to work was by adding the signInState scope outside of the Component.
That seems globally scoped? as in possibly there would be some leakage of signInState? At least in the API world, that would be the case. For Server Actions would this state be limited to a specific request/response only or possibly multiple responses?

Below works for me.

let signInState: SignInState = {
  confirmation: "",
  error: null,
};

export default async function Page() {
... 
    return (
        <form action={passwordLessSignin}>
          <EmailSignIn state={signInState}  /> {/* Client Component */ }
        </form>
    )
}

[Dev-Siri]

@cevaris
Yeah that's what I did. I added the Object outside the components and it worked. This maybe because of the revalidation of server component, it resets the state. Anyways, putting it outside is the trick.

You can find a full example here: https://github.com/Dev-Siri/fireship.io-next/blob/main/src/components/AppSignin.tsx

[karlhorky]

Wonder what happens with this signInState object and a long-running server with multiple concurrent users - does this object get shared between them? I guess that would be bad for reasons like security / UI consistency / etc

[benjick]

Doesn't this revalidate for everybody?

[codinginflow]

You can also call redirect in your server action and put the error message as a query param into the URL.

[karlhorky]

Sounds nice from a progressive enhancement perspective (use more web standards things, less client-side JS), but I guess a redirect would blow away some client-side state such as scroll position, any field data entered that isn't in the form, other state...? 🤔

[codinginflow]

Yea maybe that was a bad idea

[acomanescu]

I've been doing exactly this until I realized that I'm not only losing the state, but also the existing search query params.

[Fredkiss3]

To handle form errors in my app, i used HTTP sessions. But i had to implement them from scratch and use REDIS for storing them.

I don't really recommend anyone to go that route for this simple case and there will be soon a primitive from react to handle that, but if you want to know more, you can check out this repo : https://github.com/Fredkiss3/next-custom-session

[Fredkiss3]

here is how it works :

[Fredkiss3]

@ma13gagan in next@13.5.4-canary.2 they merged the PR which allows for progressive enhancement to work with experimental_useFormState, so this is the recommended pattern.

I created a demo for this here https://github.com/Fredkiss3/form-errors-pe
But this here is the general pattern :

// form.ts
"use client";
import {
    experimental_useFormState as useFormState,
    experimental_useFormStatus as useFormStatus,
} from "react-dom";

import { action } from "./_action";

export default function MyForm() {
    const [state, dispatch] = useFormState(action, {
        message: null,
        type: undefined,
    });

    return (
        <main>
            <h2 >useFormState demo</h2>
            <h1>Disable JavaScript to test with Progressive Enhancement</h1>

            {state?.type === "success" && <Alert>{state.message}</Alert>}

            <form action={dispatch}>
                <label htmlFor="name">Your Name</label>
                <input
                    id="name"
                    name="name"
                    placeholder="John Doe"
                    aria-describedby={`name-error`}
                    className={`border rounded-md p-2 ${
                        state?.type === "error" && state?.errors?.name
                            ? "accent-red-400"
                            : ""
                    }`}
                />

                {state?.type === "error" && state?.errors?.name && (
                    <span id="name-error" className="text-red-400">
                        {state.errors.name.join(",")}
                    </span>
                )}

                <label htmlFor="message">Your Message</label>
                <textarea
                    id="message"
                    style={{
                        width: "100%",
                    }}
                    name="message"
                    placeholder="I love cheese"
                    aria-describedby={`message-error`}
                    className={`border rounded-md p-2 ${
                        state?.type === "error" && state?.errors?.message
                            ? "accent-red-400"
                            : ""
                    }`}
                />

                {state?.type === "error" && state?.errors?.message && (
                    <span id="message-error" className="text-red-400">
                        {state.errors.message.join(",")}
                    </span>
                )}

                <SubmitButton />
            </form>
        </main>
    );
}

function SubmitButton() {
    const status = useFormStatus();
    return (
        <button
            aria-disabled={status.pending}
            onClick={(e) => {
                // prevent multiple submits
                if (status.pending) e.preventDefault();
            }}
            className={`rounded-md text-white px-4 py-2 ${
                status.pending ? "bg-blue-300" : "bg-blue-400"
            }`}
        >
            {status.pending ? "Submiting..." : "Submit"}
        </button>
    );
}

// _action.ts
"use server";
import { z } from "zod";


type ActionResult =
    | {
          type: "success";
          message: string;
      }
    | {
          type: "error";
          errors: Record<string, string[] | undefined>;
      }
    | { type: undefined; message: null };

const formSchema = z.object({
    name: z.string().min(1),
    message: z.string().min(3),
});

export async function action(prevState: ActionResult, payload: FormData) {
    const result = formSchema.safeParse(Object.fromEntries(payload.entries()));

    if (result.success) {
        return {
            type: "success" as const,
            message: `Name=${result.data.name}; Value=${result.data.message}`,
        };
    } satisfies ActionResult;

    return {
        type: "error" as const,
        errors: result.error.flatten().fieldErrors,
    } satisfies ActionResult; 
}

[benjick]

Is useFormStatus looking at the parent form to determine status? Or how does it know?

[Fredkiss3]

Yes, exactly, useFormStatus work only when called from a child of a form.

[babycourageous]

Thanks @Fredkiss3 ! This example is 🔥

[AlexMartosP]

Thanks for that! That version worked for progressive enhancement

[erfanium]

I really don't like the way of returning error as a result with 2xx status code. It's basically:

We should have control on statusCode in both client/server sides.
One idea would be to allow returning NextResponse object in server actions

[Myks92]

It seems to me that it is not very correct to return a response to each action. If we have a modular system and different developers work with each module, then we may have a different response structure in the actions of different modules. In this regard, there are suggestions:

1. Actions return a response only if it is necessary, for example, the ID of the created record.
2. Throw errors that occur when performing an action via throw new Error(). the one who calls the action can catch the necessary error through try catch.
3. Implement the ability to handle global errors such as 401,403,403 and so on. For example, through toast.
4. Pass validation errors to the client for form processing.

It seems to me that this will be the right decision. If we use errors in the form of response, then when we change the response in the api, we will have to change all the actions, instead of replacing it in one place. There is something to think about.

[v-hung]

Agreed, I want to throw errors that occur when performing an action via Throw new Error()

[benjick]

I think this makes a lot of sense, updating the UI can be done through revalidation so no need to return inserted records etc

[robahtou]

To expand on this a bit:

I would like to validate data both on the client & server. I am currently using react-hook-form along with useFormState.
The project already has a set of APIs that the client interacts with, and those APIs send back their own response codes depending on the outcome of the call. In the Server Action the response is always 200. Now we have to implement a new way on how to manage server actions responses (two different response payloads for errors). As @erfanium suggested, we should be able to control the response status code. Is there a reason from the next.js team why this cannot be done? or will it be done?

[AveshLutchman]

I think it's less that it's that they don't want it done and more that it's just still under active development and what we have is just the bare minimum for what server actions are.

[Jared-Dahlke]

yooooo, just built a whole app throwing errors in server actions expecting them to be caught in the client, only to run prod build and see it not work. Are you kidding me?

[rosariogueli]

For now I've resolved my issue by moving my client side try / catch to the server side server action, wrapping my custom errors with try / catch blocks and return an object with errors from the server action. This will result to a response without a server error (500) and then I am checking the server action response from the client component, if the response has the errors object then display my custom error there. It worked well. Now the problem i have is that i need to do this in 32 places which is a waste of time, but at least when i build the code now and run it, the annoying standard error is gone and my custom errors are displayed correctly

[YuraGB]

[rosariogueli]

Yeah kinda sucks but i also do see the benefit of this. As long as I found a way around it, how server actions work etc, I've pushed my projects forward from this issue without any other problems. Thanks

[pkpio]

There are 2 class of errors, the ones we throw and expect to be passed on to client and the ones we didn't anticipate so, safe to obscure. It would be nice if there is a special error type - say ExpectedError that can be thrown for errors we don't want to be obscure in prod.

[cehenriques]

I was also using throw new Error() on my Sever Actions to throw an error to be displayed on the client. But this method returns a 500 error response which also doesn't make sense for a validation error.
So I checked some examples and started returning a { error: ""} object. Even though it works it returns a 200 to the client, which is also confusing because I'm returning a success and an error at the same time.

Am I doing something wrong?

[wilbertvanassen]

I hope this will help someone. I had the situation where i would like to handle API responses like HTTP 403, 401, 404 etc. and, 200 OK.

Returning the error via throw new Error(errorMessage) does not work directly but we can bypass this. My server action puts the response in a function that returns an object. This object can either contain succes data or error data. That way i have an object with all the data i need (respone status, status text, message, errors and a boolean where i can check if it was an error or not).

I than just make choices based on this object.

• First i always fall back to the 'throw new Error' function when i was not able to create a response object myself.
• Than i check if the object has errors, if not: i direct the page (since that is what i want on success)
• If the object has indeed errors, it returns the full object.

Now at the form i can check if there are errors and do whatever i like.

Note: I can also return the object when it has success so i can than put that message in a toaster at my form but i was not able to do that when i use a redirect at the server action (this only returns true ofcourrse), so i ended up doings it this way.

server-action function (actions.ts)

export const signUpAction = async (
  formData: FormData,
) => {
  "use server";

  const firstname = formData.get("firstName");
  const lastname = formData.get("lastName");
  const email = formData.get("email");
  const password = formData.get("password");
  const country = formData.get("country");

  // Create an object with the desired structure
  const requestData = {
    firstname: firstname,
    lastname: lastname,
    email: email,
    password: password,
    country: country,
  };

  const response = await fetchServer({
    method: "POST",
    url: `${domain}/api/website/sign-up`,
    body: JSON.stringify(requestData),
  });

  let responseObject = await createResponseObject(response);

  // Fallback if response object is null
  if (!responseObject) {
    const errorMessage = response.statusText || "Something went wrong";
    throw new Error(errorMessage);
  }

  // Redirect to homepage if sign-up is successful
  if (responseObject.error === false) {
    redirect("/");
  }

  // If response object is not null the function will return the response object
  return responseObject;
};

The function that creates the response object

"use server";

export async function createResponseObject(response: any) {
  const defaultErrorMessage = "Something went wrong";

  if (!response.ok) {
    const errorResponse = await response.json();

    if (!errorResponse.message) {
      return false;
    }

    return {
      message: errorResponse.message || defaultErrorMessage,
      status: response.status || 0,
      statusText: response.statusText || defaultErrorMessage,
      errors: errorResponse.errors || {},
      error: true,
    };
  }

  if (response.status && response.statusText) {
    return {
      message: "Success",
      status: response.status,
      statusText: response.statusText,
      error: false,
    };
  }

  return null;
}

My form that runs the server action (this is a client component)

 async function clickHandler(formData: FormData) {
    try {
      const response = await signUpAction(formData);

      if (response?.error === true) {
        toast.error(response.message);
        return;
      }

      toast.success("Success! You are now signed up!");
    } catch (e) {
      const error = e as Error;
      toast.error(error.message);
      return;
    }
  }

Have a nice day!

[benjick]

Also check out next-safe-action, it does this and supports middleware.

[RinNguyens]

Right now, I use Next-safe-action handle server action. I help me a lot for response status like HTTP.

[browynlouis]

Nice, around last year, I built a custom hook very much similar to the one above to solve this problem and around last week I thought of taking it further into a whole library, then I came across next-safe-action and it's really beautiful 😻

[RinNguyens]

yeah, first time I was use react tanstack query in react. Then move to Nextjs use Next-safe-action. Wow, it's help me a lot for server action, simply and fast.

[markedwards]

So now that useActionState ships with react, I want to use it. However, I get this error from Next if I try:

TypeError: (0 , react__WEBPACK_IMPORTED_MODULE_1__.useActionState) is not a function or its return value is not iterable

Caused by:

import { useActionState } from "react";

Do we have to wait for support from Next?

[karlhorky]

Try the canary versions, it's there

[markedwards]

I'm okay to wait for it, I just wanted to confirm that Next needs an update here.

[koichik]

JFYI, #65058

[JacksonMalloy]

What I've been doing is using transitions and toast.promise for my actions...

For example:

const [isUpdatePending, startUpdateTransition] = React.useTransition();

...

 startUpdateTransition(() => {
  toast.promise(
    rescheduleSessionAction({
      accountId: props.session.account_id,
      workoutId: props.session.workout_id,
      operation: "reschedule-to-today",
      toDate: new Date(),
    }),
    {
      loading: "Updating training calendar...",
      success:
        "Training calendar updated successfully",
      error: "Failed to update training calendar",
    },
  );
});

Handles all three states

1. When the UI action occurs, the loading state shows in the toast
2. When the action returns successfully, the success state shows in the toast
3. When the action throws an error (outside a trycatch) the toast shows the error state.

It's been a super clean way of doing things :)

[leerob]

Hey everyone, I just updated our docs with guidance on handling errors with Server Actions!

https://rc.nextjs.org/docs/app/building-your-application/routing/error-handling

[ADTC]

Following the advice of @sam3d is easier if you abstract it into a reusable:

queryFn: withServerError(myServerAction),

Then the reusable:

export const withServerError = (serverAction) => () =>
    serverAction().then((v) => {
      if (v.error) throw v.error;
      return v;
    })

[sam3d]

@ADTC I mean I wouldn't exactly call it verbose. Your wrapper also assumes that the shape of the error will be the same for every wrapped action, in which case you may probably also want to develop an abstraction that wraps server actions to return errors in that shape. Could even make a ClientError that is handled specially to retain the ability to throw those:

class ClientError extends Error {}

function action<T extends any[], U>(
  fn: (...args: T) => Promise<U>,
): (
  ...args: T
) => Promise<{ error: string; data?: never } | { error?: never; data: U }> {
  return async (...args: T) => {
    try {
      return { data: await fn(...args) };
    } catch (err: unknown) {
      if (err instanceof ClientError) return { error: err.message };
      throw err;
    }
  };
}

And then use it like so:

"use server"

export const getUser = action(async (id: string) => {
  if (id !== "test") throw new ClientError("show this to the client");
  return { id, name: "Test User" };
});

getUser("test").then((v) => {
  if (v.error) throw new Error(v.error);
  return v.data;
});

[cobbvanth]

@sam3d Thanks so much for this, this is a really nice and clean solution! Much appreciated

[markomitranic]

I wrote a piece about teaching this to my colleagues, and attached a simple copypasteable wrapper that we use nowadays, not dissimilar to what @sam3d posted above! https://medium.com/homullus/safe-r-usage-of-react-server-actions-with-rhf-and-tanstack-query-b1c79d8894a0

Hope you find it useful

[abed-daloopa]

Hey everyone, I just updated our docs with guidance on handling errors with Server Actions!

https://rc.nextjs.org/docs/app/building-your-application/routing/error-handling

The docs imply that uncaught server action exceptions can be caught using an error boundary component (error.tsx file) and this is only true during development.

In production, this does not work. The docs are misleading here.

Please update the docs.