[Feature Request] - core - add unique request identifier to logs to better trace issues

[nagi1]

Is your feature request related to a problem? Please describe.

When debugging customer issues, I need to trace a request across multiple systems: my backend → Waha → my backend again (webhooks). Currently this is nearly impossible because:

1. Waha's req.id is a monotonically-increasing integer (110974, 110975, ...) not a UUID. It resets on restart and can't be correlated with external systems.
2. Waha's req.id is only visible in internal pino log output. It's never exposed to callers via response headers.
3. The custom req serializer logs only {id, method, url, query, params} there's no mechanism to include a caller-supplied trace ID.

Describe the solution you'd like

1. Add a genReqId override that generates UUIDs (e.g., crypto.randomUUID()) instead of integer counters. This makes request IDs globally unique and restart-safe.

2. Return the request ID in a response header (e.g., X-Request-Id or x-request-id). Callers can capture this and correlate it with their own tracing systems (New Relic, Sentry, Graylog, etc.). A simple NestJS interceptor that reads req.id and sets the response header would suffice.

3. Accept a caller-supplied trace ID via an incoming request header (e.g., s-request-id or x-request-id). If present, use it as req.id instead of generating a new one. This allows a caller like my backend to propagate its own trace ID through Waha's logs.

Describe alternatives you've considered

• Parsing Waha's Docker logs from the outside Fluentd processes log streams, not per-request. No way to inject context.
• Reverse proxy header injection Waha's custom req serializer doesn't include headers. The default genReqId doesn't read headers either.
• Forking Waha maintenance burden, diverges from upstream.

Proposed implementation (in src/core/app.module.core.ts):

LoggerModule.forRoot({
  pinoHttp: {
    // Read s-request-id or x-request-id from incoming headers, fallback to UUID
    genReqId: (req) => req.headers['s-request-id'] 
                      || req.headers['x-request-id'] 
                      || crypto.randomUUID(),

    // Echo the request ID back to callers
    customProps: (req, res) => {
      res?.setHeader?.('x-request-id', req.id)
      return {}
    },

    // ... existing config unchanged
  },
})

Additional context

My backend sends ~100k+ requests/day through Waha. Being able to search New Relic for a Waha request ID and find the corresponding backend request (and vice versa) would reduce debugging time from hours to minutes.

[devlikepro]

+1

[nagi1]

+1

@devlikepro Wanna me to propose a PR?

[devlikepro]

@nagi1 If it's done by hands - yes; if it's "as-is" AI bulshit - no.

[nagi1]

@devlikepro this was just a proposal more of pseudo code the implementation will be much more cleaner and covered by 100% feature test.

if you already have done it or planning to do it in this release I can leave it to you, otherwise I suggest creating a PR for review it's a small change BTW on waha only wont touch engines (GOWS, NOWEB ...)

[nagi1]

@devlikepro #2179