What is the best place to generate a request-id and log it?

[PoppinMic]

Hi community,

Since Next.js plays as a server, our dev team want to be able to log it and generate/attach a consistent request-id for all the http requests initiated by Next.js(unless refresh or request another page). After some days of research I couldn't find an optimal solution still. I only see examples using a custom server but that is not recommended by Next.js team.

The documentation mentioned pino but there is no guidance on how to use it without a custom server. I tried to use middleware but I don't know where to pass on the x-request-id in response header to the next request in middleware so the requestId will be different on each asset request.
An exmaple would be like

 browser visit a page 
  -> nextjs server generate `{requestId: uuid-1}`
  -> nextjs server send 3 request for different resources(image, api, etc) 
  -> all the 3 request has the same `requestId` and are being logged

Any suggestion will be much appreciated.

[ArunJRK]

You could do it in middleware.ts

[Nadeera3784]

Hi @PoppinMic,
You can simply use middleware.ts.
for example :

import { NextRequest } from 'next/server';

export default async function middleware(request: NextRequest) {
  // Get the request-id
  const requestId = request.requestId;

  // Console.log the request-id
  console.log('The request-id is:', requestId);

  // Continue with the middleware
  await NextResponse.next();
}

[saikiranmarripati]

This is not working in "next": "14.2.3"

[AlonMiz]

The request ID is essential for debugging and is a fundamental aspect of logging and tracing. As a developer, I need all my logs to include the corresponding request ID. From a technical standpoint, we know that Vercel logs an access log, which likely includes a request ID within that context. How can we retrieve it from the code? Is there an environment variable, metadata on the request, or another method to access it?

[camjackson-bigwx]

@jsardev have you been able to get AsyncLocalStorage to work during the react render on the server?

I've got a custom _app.tsx which already has its own getInitialProps. I'm currently generating a requestId in there, and then wrapping the whole getInitialProps with storage.run(), and it works quite well. I can do storage.getStore() anywhere during the data fetching phase on the server and retrieve my requestId. I can also return the requestId so that it traces through to my root App component (just normal initial props behaviour).

The problem I've found is that react components seem to break the async context somehow. In my App component I have wrapped the whole component body in storage.run(), and I can even then retrieve the request ID from storage as long as I do it within that same root App component. But whenever I try to do storage.getStore() from a child component, even a very simple one, it returns undefined.

I should mention that this is all using the pages router, not the app router. Basically this (real code is a little more complex, I have created an isomorphic abstraction over AsyncLocalStorage so that it uses the real thing on the server, and just uses window in the browser):

// _app.tsx

// requestId comes from getInitialProps (not shown)
const App = ({ requestId }) => {
  return storage.run({ requestId }, () => {
    // this works!
    console.log('requestId in App:', storage.getStore()?.requestId) 
    
    return <Child />
  })
}
export default App

const Child = () => {
  // getStore() returns undefined :(
  console.log('requestId in Child:', storage.getStore()?.requestId)

  return <div>hey</div>
}

If I change my App component to do return Child() then it works, which is even more bizarre. There's something specific about react component rendering that seems to break the async storage context. Obviously I could use normal react context for this, but I don't want to. I want to be able to look things up directly from the store from absolutely anywhere, not just from components or hooks.

Anyone know what the hell is going on? I'm struggling to find any concrete references on using AsyncLocalStorage with react + next.js.

[jsardev]

@camjackson-bigwx It works for me with the App Router. What I'd try in your case would be to use storage.enterWith() instead of wrapping everything with storage.run() - just run it at the start of your App function body.

[camjackson]

Thanks @jsardev. Unfortunately I can't use the App Router at the moment because of its incompatibility with CDN caching (see #65335).

I had a look into enterWith and its differences from run. The Node.js docs are a little bit light on details, but they seem to recommend against using enterWith unless you know exactly what you are doing. Which I don't 😅

My concern is that enterWith might bleed context between concurrent requests. Is that a valid concern?

[jsardev]

@camjackson Yes, it's surely less safe than run(), but it works fine in my case.

What you could also check is this package: https://nimpl.dev/docs/context - but from what I see it also leverages enterWith: https://github.com/alexdln/nimpl-context/blob/e063817939c5b018362569370ab6ca266c612f96/package/src/create-server-context.tsx#L7-L10

My concern is that enterWith might bleed context between concurrent requests. Is that a valid concern?

I don't think so. How I understand this is that if you run enterWith within the request context (what you'll do when running it inside any of the Next.js API, perhaps apart from instrumentation which might run very early in the process) the storage will remain for any sync and async execution within current context. When a new request starts - there's no more access to that storage.

node process -> spawns request -> call enterWith -> storage remains in everything created from now on from this context, but new requests are not spawned/executed within previous requests, the context goes back to the node process which is outside of the created AsyncResource created in the previously spawned request

That's how I understand it. Not sure if I explained it clear enough but I tried 😅 You can test it out in some quick sandbox - it seems to be working as expected.

[camjackson]

Thanks @jsardev, I had been too scared to use enterWith based on the Node.js docs recommending against it, but your comment gave me the confidence to just try it myself and do my own testing. As far as I can tell, it's working great. I can call enterWith right at the start of App.getInitialProps, and it persists all the way through both the getInitialProps phase and then also through the react render as well, which is excellent.

I've been spamming my local server with concurrent requests and there is no bleeding of context between requests either, so it's working exactly as you said.

Thanks heaps, this is just what I needed!