handleServerErrorLog should have access to metadata / inputs

[Gawdfrey]

First of all I want to state the next-safe-action is an amazing library, and makes server actions so awesome to work with at scale.

I have a bit of a nuisance when it comes to the handleServerErrorLog method. When we log, we usually attach metadata to the log to better trace it. I am able to attach a correlationId, but i would also like to log other properties that I pass from the specific action. I am also using a separate logging middleware, to log inputs and validation errors.
Since the error is not passed to the logging middleware, I am using (misusing) the handleReturnedServerError method to return the error itself, then I am able to access it in the logging middleware. I log the error there, then I overwrite the result.error.serverError to not bleed the entire stacktrace to the client.

This feels very hacky and could probably be solved a lot better if other properties were exposed to the handleServerErrorLog method.
I am also wondering if the handleServerErrorLog has any right to life, if the error itself was exposed to the middleware? Probably solved the way it is for a reason...

Example:

import { getRegularLogger } from "@/logger";
import { createSafeActionClient } from "next-safe-action";
import { z } from "zod";

export const actionClient = createSafeActionClient({
  handleReturnedServerError(error) {
    // passing the error to the logging middleware
    return {
      error,
    };
  },
  defineMetadataSchema() {
    return z.object({
      actionName: z.string()
    });
  },
}).use(
  async ({
    next,
    bindArgsClientInputs: [id, stepId],
    clientInput,
    metadata: { actionName },
  }) => {
    const logger = await getRegularLogger();
    const context = {
      StepId: stepId,
      StepCode: stepCode,
      ApplicationId: id,
    };
    logger("Information", {
      body: {
        input: clientInput
        stepId,
        id,
      },
      ...context,
    });
    const result = await next({ ctx: null });
    if (!result.success) {
      const t = await getTranslations("serverError");
      logger("Error", {
        ...context,
        validation: {
          errors: [result.bindArgsValidationErrors, result.validationErrors],
        },
        error: JSON.parse(
          JSON.stringify(
            result.serverError?.error,
            Object.getOwnPropertyNames(result.serverError?.error),
          ),
        ),
      });
      // overwriting the error to not bleed it to the client
      result.serverError = {
        error: "Something went wrong"
      };
    }

    return result;
  },
);

Thanks!

[TheEdoRan]

Starting from v7.1.3, both handleReturnedServerError and handleServerErrorLog functions get util props as their second argument. More information about that here. handleServerErrorLog also has access to returnedError now, in addition to the originalError, so it's much more flexible.

I am also wondering if the handleServerErrorLog has any right to life, if the error itself was exposed to the middleware? Probably solved the way it is for a reason...

handleServerErrorLog is there since the beginning, when the library only supported one monolithic middleware defined at the instance level. Now you can handle logging both inside middleware functions and in handleServerErrorLog. I think it's fine to offer both ways to interact with server errors, for example the default log behavior of next-safe-action is to print to console the server error message in the form of: "Action error: [server error message]". Using handleServerErrorLog you can customize that behavior and even disable logging entirely if you want.

[Gawdfrey]

Thank you, perfect! Appreciate 😄