Middleware wrapping call with AsyncLocalStorage.run()

[crummy]

The moment a request comes in, I'd like to generate a traceId, which I'll include in any logs my application generates. Here's how I do this with a different API library (TRPC):

const traceIdStorage = new AsyncLocalStorage<string>();
export const internalProcedure = internal.procedure.use(({ next }) => {
    return traceIdStorage.run(randomUUID(), async () => {
      const result = await next({ ctx });
      if (!result.ok) {
        logger.error("Something went wrong", result.error);
      }
      return result;
    });
  },
);

I set up my logger to read from traceIdStorage so I can include that data in any logs I send.

I'd like to do the same with express-zod-api, but the middlewares are a little different - there's no next object I can call in my .run() argument. Is there another way to achieve this?

[crummy]

Think I've found it:

const config = createConfig({
  server: {
    listen: 8090, // port or socket
    compression: true,
    beforeRouting: ({ app }) => {
      app.use(({next}) => {
        return traceId.run(randomUUID(), async () => {
          try {
            if (next) next()
          } catch (e) {
            console.error("Uncaught exception", e)
            throw e;
          }
        })
      }
    }
  },
}

However, it would be handy to be able to do it later, where I have figured out who my user is (then I can attach usernames etc to my logger context)

[crummy]

This doesn't really work it turns out - it seems I do not have access to the traceId within my code, perhaps next is not being called as I expected, or something else is going on.

[RobinTail]

if you wanna go this way, next should be the third argument of app.use

[crummy]

That worked great too! @RobinTail thanks so much for your hard work and support!

[RobinTail]

Hello, @crummy

There is a dedicated article on that topic:
https://github.com/RobinTail/express-zod-api?tab=readme-ov-file#child-logger

Implying that your logger has a .child() method:

import { createConfig } from "express-zod-api";
import { randomUUID } from "node:crypto";

const config = createConfig({
  // logger: ...,
  childLoggerProvider: ({ parent, request }) =>
    parent.child({ requestId: randomUUID() }),
});

Basically you simply create another instance of the logger inside that function, that somehow displays the request ID.
So that you don't even need the storage — this approach enables a dedicated instance of the logger for the individual request.
I hope it helps.

[crummy]

Thanks! That's a little less elegant than the AsyncLocalStorage but it works fine enough for me.

For posterity, here is how I set up my logger:

  childLoggerProvider: ({ parent, request }) => {
    const traceId = randomUUID();
    if (request.res) {
      request.res.locals = { traceId };
    }
    return parent.child({ traceId, path: request.path });
  },

Later I have a middleware that extracts the traceId:

   createMiddleware({
      const traceId = request.res?.locals.traceId;
      return { traceId }
  })

And then I use this to retrieve it:

  handler: async ({ input, logger, options }) => {
    const traceId = options.traceId;
  }

[RobinTail]

Wonderful.

• I will add response to childLoggerProvider, so that you'd not need to refer to it via request.res, @crummy .
• In the createMiddleware you can take it directly from response which is already available there.

Could you clarify one more thing for me regarding traceId in the endpoint handler:

a traceId header to a fetch request later on

If that the fetch from some other external data source needed for your API to respond?
Like your API is using another API — is that correct?
Because if so, I have one more idea, but I need to ensure that I understand the use-case correctly.

[crummy]

Yes, my express-zod-api service sometimes makes HTTP calls to other services we maintain. Ideally we generate a traceId the moment we receive a public request, and then hand that traceId to any other services, who pass it on, etc.

So later on I make a request like:

fetch(`${internalService}/api/whatever`, { headers: { 'trace-id': asyncLocalStorage.getStore() } }

[RobinTail]

Ok. While I'm thinking on a better approach, here is one more suggestion on excluding request.res.locals from that:
Some sources state that it's actually a normal practice to add custom properties to request, like this:

declare global {
  namespace Express {
    interface Request {
      traceId?: string;
    }
  }
}

https://dev.to/kwabenberko/extend-express-s-request-object-with-typescript-declaration-merging-1nn5
https://stackoverflow.com/questions/37377731/extend-express-request-object-using-typescript

So in childLoggerProvider you can set request.traceId and then promote it as an option for endpoints using middleware, but taking it from request — that would probably improve clarify and semantics, @crummy

[RobinTail]

Update on this topic.
Starting v19.2.0 .child() method added to the built-in logger