`setError()` doesn't work from inside error handler in Fastify

[luismiramirez]

The error-handling helpers from our library don't behave as expected when used inside Fastify error handler middleware.

Calling the OpenTelemetry API directly works. Using recordException() on the active span.

Internal link

[luismiramirez]

I couldn't reproduce using setErrorHandler() in Fastify 4 and 5. Both helpers setError() and sendError() work just fine. However, as the customer reported, they stop working when you set up a preHandler().

Here's a related issue from OpenTelemetry's official plugin, which is exactly the problem the customer is having. -> open-telemetry/opentelemetry-js-contrib#2355

[flo-sch]

I am also facing this in a fastify v5 app.
Only setError has no effect in my case (potentially due to the instrumentation issue linked above?), sendError works as expected.

For what it's worth, my app is built with NX in a monorepo, as a @nx/node:app, and runs using node main.js instead of the fastify CLI (which is uneasy to use in a monorepo).

Here is what the server looks like:

import { Appsignal, sendError } from "@appsignal/nodejs";
import Fastify from 'fastify';
import pino, { TransportTargetOptions } from "pino";

// configure logger with appsignal transport
const targets : TransportTargetOptions[] = [
  { target: 'pino/file', options: { destination: 1 } }, // stdout
];

if (Appsignal.client?.isActive) {
  targets.push({
    target: "@appsignal/nodejs/pino",
    options: {
      group: "app",
    },
  });
}

const logger = pino({
  level: 'error',
  pino.transport({
    targets,
  }),
});

const server = Fastify({
  loggerInstance: logger,
});

// configure fastify error handler to report unhandled errors to appsignal
server.setErrorHandler((error, request, reply) => {
  // setError(error); // --> has no effect, perhaps since there is no current active span to link the error to?
  sendError(error); // --> reports correctly
  return reply.status(500).send({ message: 'internal server error' });
});

// register plugins and routes etc. etc.

server.listen((error) => {
  if (error) {
    sendError(error);
    process.exit(1);
  }
});

I run it aside of a configured appsignal.cjs file (added as a NX "asset" to the built folder).
It is built with NX then deployed as a docker container doing more or less:

FROM docker.io/node:jod-alpine
RUN apk add --no-cache dumb-init g++ make openssl python3

ARG APP_REVISION
ENV APP_REVISION=${APP_REVISION}

WORKDIR /app

COPY dist/apps/<my-app> ./ 

ENV NODE_OPTIONS="--enable-source-maps --require=./appsignal.cjs"

ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["node", "main.js"]

[unflxw]

Separate conversation about this issue on Intercom (private link): https://app.intercom.com/a/inbox/yzor8gyw/inbox/admin/5246522/conversation/215469559868778#part_id=comment-215469559868778-26139412631

It seems that the issue might be fixed when using newer versions of fastify and @fastify/express -- waiting for confirmation from the customer.