The digest code of error is not usable

[Amerehei]

Summary

Please read getsentry/sentry-javascript#10071 (reply in thread) frist

I would like to send the digest code as a tag to Sentry when it reports the error log. It's not possible!

I'm wondering what the point of digest code when we cannot use it! The only place the digest code exposed is in the error.js and global-error.js and as I found the next.js only provide digest for SSR errors and in the error.js and global-error.js for security reason the error manipulated to avoid leaking sensitive details.

Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error..

My questions are:

1. How can we utilize effectively the digest code when we report an error?
2. Is there any function to pass Error object and calculate digest for it? it can help me to recalculate the digest in the beforeSend hook of Sentry

The other problem is #60245

Additional information

No response

Example

No response

[Amerehei]

Is there any alternative way to show the user a UUID as a tacking id and tag the SSR error using the same UUID?
I mean sharing some UUID between the backend error and rendered page

[lucaf1990]

up

[Gawdfrey]

Probably too late to the party, but I have resolved the matter of exposing the digest code in a third-party logger, by creating a service worker that is called each time the error page is thrown. The service worker sends an API call which again send a server-to-server request to the third-party logging service.

But alas, I am struggling to find the counterpart digest on the server side and report it to the third-party logger

[Amerehei]

@Gawdfrey Wow! can you explain more about your solution?

[Gawdfrey]

Sure. Hopefully these snippets explain everything :)
There are some drawbacks to this though. Serviceworkers can be a pain to update, since they are cached by the user. But hopefully this is code that doesnt have to change often :)

serviceworker.js
The service worker code it self. I do believe it needs to be located in the public folder, might be mistaken though.

/* eslint-disable no-console */
let buffer;

self.oninstall = function (event) {
  event.waitUntil(self.skipWaiting());
  buffer = [];
};

self.onactivate = function (event) {
  event.waitUntil(self.clients.claim());
};

const handleBuffer = () => {
  const messages = buffer.splice(0, buffer.length);
  if (messages.length) {
    fetch("/api/log", { method: "POST", body: JSON.stringify(messages) }).catch(
      console.warn,
    );
  }
};

setInterval(handleBuffer, 5000);

self.addEventListener("message", function (event) {
  const { data } = event;
  if (!buffer) {
    buffer = [];
  }
  if (data.type === "log") {
    buffer.push([data.level, data.location, ...data.args]);
  }
});

MountServiceWorker.tsx
Mounts the service worker. Wrap you dom tree in the root layout file with this.

import Script from "next/script";

export function MountServiceWorker() {
  return (
    <Script
      type="text/javascript"
      id="sw-reg"
      dangerouslySetInnerHTML={{
        __html: `if (!navigator.serviceWorker.controller) {
  navigator.serviceWorker.register('/service-worker.js').then(registration=>registration.update());
}`,
      }}
    />
  );
}

/api/log/route.ts
You now have the log on the server and can do whatever you want with it!

import { getLogger, withLogger } from "@lib/logging/logger";
import { NextRequest, NextResponse } from "next/server";

export const runtime = "edge";

const logEndpoint = async (request: NextRequest) => {
  const logger = getLogger(request);
  const logs = await request.json();
  logs.forEach(([level, location, ...log]: unknown[]) => {
    logger(level as any, {
      location,
      ...log,
    });
  });
  return NextResponse.json({ success: true });
};

export async function POST(req: NextRequest, res: NextResponse) {
  return withLogger(logEndpoint)(req, res);
}

error.tsx
User is router here by NextJS on error.

"use client";

import { clientLogger } from "@lib/logging/client-logger";
import { useEffect } from "react";

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  useEffect(() => {
    clientLogger.error(error.message, error.digest);
  }, [error]);
  return <h1>Error</h1>;
}

clientLogger.ts
This is what triggers the service worker to send an api request.

"use client";
import { LogLevel, isEnabledLogLevel } from "./log-level";

const logWrapper =
  <T extends Array<unknown>>(level: LogLevel) =>
  (...args: T) => {
    if (!isEnabledLogLevel(level)) {
      return;
    }
    globalThis.navigator?.serviceWorker?.controller?.postMessage({
      type: "log",
      level,
      location: globalThis.location.href,
      args,
    });
  };

export const clientLogger = {
  info: logWrapper("Information"),
  warn: logWrapper("Warning"),
  error: logWrapper("Error"),
};

[Amerehei]

Thanks for sharing your solution
I didn't understand what's the point of service worker? Why don't you directly call API in useEffect of error.tsx

Still I don't know how it's possible to connect it to Sentry when we are dealing with auto error report

[howiesommerfeld]

I'm also struggling to find the digest property on my server logs. The Vercel runtime logs don't return anything when searching using the digest - am I missing something?? I would imagine that you'd be able to use the generic error message's digest returned on the client side (in my case it's being logged on Sentry) in order to search for the corresponding detailed error on Vercel?

[SergioGeeK7]

is there any update on this, I'm also picking up the digest id returned on error.js, and using it to search server logs and don't find anything