Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add request-id correlation to structured logs and `X-Request-Id` response header

Open
  • Is something wrong?
#218 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
node.js, typescript
Domain
backend, observability

Research direction

Start in src/main.ts, where the new middleware must be registered before routing, then read src/common/middleware/request-timing.middleware.ts (line 57) and src/common/middleware/profiling.middleware.ts (line 11), which each generate a request id. Consolidate those into one id from crypto.randomUUID(), reuse a valid inbound X-Request-Id, and echo it in the response header. Done means every response carries the header, a malformed inbound value is replaced, and a test covers all three cases. The logging-context binding depends on the logging-facade decision, so confirm that first.

Written by the indexing model from the issue text.

Description

enhancement help wanted intermediate

Problem

src/main.ts does not set app.enableVersioning(), and there is no request-correlation middleware. Tracing exists — src/observability/tracing.interceptor.ts, request-timing.middleware.ts, and OpenTelemetry are all present — but a single log line cannot currently be tied back to one inbound request across services.

The middleware files do generate ids: src/common/middleware/request-timing.middleware.ts:57 and src/common/middleware/profiling.middleware.ts:11 both derive a request id, and both use Math.random() (see the Math.random() issue). There is no middleware that stamps an id onto the logging context or echoes it back to the caller.

Why it matters

During an incident, correlating a user report ("my submission failed around 14:32") to the right log lines is guesswork without a correlation id. The OpenTelemetry trace id exists but is not surfaced in the logs or in responses, so a support conversation cannot start from a trace id either.

This is also the single highest-value prerequisite for making the logging cleanup meaningful — a single facade is much less valuable without correlation.

Suggested Direction

  1. Add a RequestIdMiddleware registered in src/main.ts before routing:
    • Reuse an inbound X-Request-Id if present (needed so a gateway or client can propagate it), otherwise generate one with crypto.randomUUID().
    • Attach it to the request so downstream handlers can read it.
  2. Echo it back as an X-Request-Id response header. Low cost, high value for clients reporting problems.
  3. Bind it into the logging context so every log line emitted during the request carries the id. This depends on the logging-facade decision in the logging issue — do that one first, or land this as the mechanism the facade will later consume.
  4. Include it in the OTel context so logs and traces join on the same id.
  5. Reconcile with the existing two middleware that each generate their own id. There should be exactly one request id, generated once.

Constraints

  • Do not trust an inbound X-Request-Id blindly. Validate its format (UUID or similar) and regenerate if it does not conform, otherwise a client can inject arbitrary content into every log line.
  • Generate with crypto.randomUUID(), not Math.random().
  • Correlation ids can end up in logs; do not place secrets in them.

Acceptance Criteria

  • Every response carries an X-Request-Id header.
  • A valid inbound X-Request-Id is reused; a malformed one is replaced.
  • The id appears on every log line emitted during the request.
  • Only one request id is generated per request (the two existing Math.random() sites are consolidated).
  • A test asserts header generation, pass-through, and rejection of a malformed inbound value.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.