@bymax-one/nest-logger 1.3.0 → 1.4.0

package/CHANGELOG.md

@@ -11,6 +11,193 @@ heading here.
 
 ## [Unreleased]
 
+## [1.4.0] - 2026-08-30
+
+No breaking changes. Nothing you have wired stops working, and no export was renamed.
+
+### Added
+
+- **`applyAccessLog(app)` — the access log mounted ahead of the body parser.** A request the body
+  parser rejects never reaches module middleware, so until now it never reached the access log
+  either. NestJS registers the parser one line before it registers module middleware
+  (`@nestjs/core/nest-application.js`: `registerParserMiddleware()` then `registerModules()`), and
+  Express dispatches in registration order, so `next(err)` from the parser skips every remaining
+  non-error handler — module middleware, guards, interceptors and the route handler alike. A `POST`
+  carrying truncated JSON produced no access log at all, and the same hole covers a payload over the
+  body limit and an unsupported content type: the requests a client got wrong or an attacker shaped.
+
+  What you got before this release depended on your wiring, and neither answer was good. With
+  `forRoot` and the default `shouldCaptureExceptions`, the filter **did** catch the parser rejection
+  and emit one `HTTP_EXCEPTION_HANDLED` line — measured, not assumed — but with **no `requestId`**,
+  because the correlation scope is mounted behind the parser too and never opened. The client could
+  send `x-request-id` and the entry carried nothing to join it to. With `forRootAsync`, or with
+  `shouldCaptureExceptions: false`, there was nothing at all. A 400 you cannot trace to the caller
+  is the same defect as a missing 400, wearing a healthier face.
+
+  `INestApplication.use()` delegates straight to the HTTP adapter and `init()` — where the parser is
+  registered — does not run until `listen()`, so mounting from `main.ts` lands ahead of the parser,
+  the same reason `helmet` and `cookie-parser` are mounted that way. `HttpAccessLogMiddleware`
+  needed no new logic to work there: it already emits from the response's `'close'` event, reading
+  `statusCode` and `writableFinished`, so it never depended on a route matching, a handler running
+  or a filter catching anything. It was written correctly and mounted too late.
+
+  One line in and one line out now cover the parser rejection, the unmatched-route 404, the guard
+  rejection and the aborted connection alike. Call it after `NestFactory.create()` and **before the
+  application initializes** — that is, before `app.init()`. `listen()` only triggers `init()` when it
+  has not already run, so "before `listen()`" is the same deadline for the usual bootstrap and the
+  WRONG one for a serverless entry point or an integration test that does `await app.init()` and
+  wires up afterwards: that mount lands behind the parser and logs nothing extra, with no error to
+  say so.
+
+- **`HttpAccessLogMiddleware` is exported.** Without the class, an early mount was impossible to
+  express — a consumer with its own bootstrap sequence had no way to reach it. It is the same class
+  `applyRequestIdMiddleware` has always wired; only its visibility changed.
+
+- **`LogContextService.runMerged(context, callback)`** — a scope that EXTENDS the enclosing one
+  instead of replacing it, for the case where an inner scope is genuinely a refinement of the outer:
+  adding a `userId` once authentication resolved it, without restating the `requestId` the
+  middleware already set. Outside any scope it behaves exactly like `run()`. Writes inside it never
+  reach the enclosing context — the merge produces a fresh object.
+
+### Fixed
+
+- **Two mounts of `RequestIdMiddleware` minted two different correlation ids.** `use()` sets the id
+  on the RESPONSE header and never writes it back onto `req.headers`, so a second mount with no
+  inbound header saw nothing and minted its own: the outer set the response header to one UUID and
+  the inner overwrote the log context with another, leaving the header and the entries disagreeing
+  about which id the request had. Each answer was internally consistent, which is why it survived —
+  nothing looked broken from either side alone.
+
+  The middleware is now idempotent, off two marks kept on the REQUEST rather than off a header
+  write-back. Writing the minted id back onto `req.headers` would have worked and was rejected
+  deliberately: it conflates "the client sent this id" with "we minted this id", and anything
+  downstream treating an inbound header as client-attested would start reading our own UUID as the
+  caller's.
+
+  **What is adopted is the id this library validated for this request — not whatever the log context
+  happens to hold**, and the difference decides how a gateway-provided id has to be passed. An id
+  that reaches the middleware only through an enclosing `LogContextService` scope is never adopted
+  and never echoed. With generation on, the request gets its own id: the inbound `x-request-id`, else
+  a fresh UUID. With `shouldGenerateRequestId: false` and no inbound header, an enclosing `requestId`
+  is inherited into the request's entries but no response header is set. **To have an upstream id
+  echoed, send it as `x-request-id`.**
+
+  The marks are two because they answer two questions and either can be true alone. One records that
+  a scope for this request was opened, and decides whether a second mount opens another. The other
+  records the validated id, and decides what may be echoed — read from the request rather than the
+  store, so a value middleware replaced between the mounts (`set()` takes `unknown`) cannot reach the
+  response header. The adopt path also **restores** the validated id to the active context, because
+  the emitted entry reads `requestId` from the store: echoing one value while leaving another in the
+  store would produce the same header/entry split this change exists to remove.
+
+  The request's own scope now starts from the enclosing scope's fields rather than from nothing,
+  which fixes a second thing in the same place: a consumer that opened its own scope upstream — a
+  tenant resolved at the edge — had it **discarded** for the whole request, because `run()` replaces
+  the context.
+
+  What it inherits is an ALLOWLIST — `requestId` and `tenantId`, the library's own correlation
+  fields — and that shape took three review rounds to reach. A denylist cannot be made safe here:
+  `LogContext` explicitly permits arbitrary consumer keys, so an application-defined `accountId` or
+  `sessionId` misattributes a request exactly the way `userId` does, and no list of forbidden names
+  is ever complete. Measured on the denylist version: a request opened inside a scope holding
+  `{ accountId, sessionId }` inherited both.
+
+  The identity cases the denylist did catch are worth recording, because they are what the allowlist
+  now covers by construction. `userId` is resolved by a guard that runs after this middleware, and
+  the mixin copies the store onto every entry while `PinoLoggerService` deliberately does not write
+  `userId: undefined` when the argument is omitted — so an anonymous request inside a scope holding
+  `userId: 'admin-u1'` was logged under `admin-u1`. Trace fields leak the same way, in every naming:
+  the mixin overwrites them from the active span but only when there IS one, and the field names are
+  configurable (`otel.fieldFormat: 'snake_case'` renames all three), so a literal exclusion was
+  wrong in both directions at once.
+
+  Dropping a field a consumer set upstream is not a regression — before this release `run()`
+  discarded all of it — and it fails in the safe direction: a missing field is visibly missing,
+  where an inherited identity is wrong while looking right.
+
+- **A `g` or `y` flag on an `excludePaths` pattern excluded the path only every other time.**
+  `RegExp.prototype.test` on such a pattern advances its `lastIndex` and resumes from it, so the
+  same pattern tested twice against the same path returns `true`, then `false`. Measured on
+  `/^\/health$/g` against `/health`: `true, false, true, false`. The patterns live in module
+  options — one frozen array shared by the access-log middleware and the HTTP interceptor for the
+  lifetime of the process — so a consumer who carried a `g` flag in from a copied pattern saw
+  excluded health checks reappear at half rate, with no error and nothing to suggest the config was
+  not working.
+
+  This predates `1.4.0`; mounting both wiring helpers only made it sharper, because the two mounts
+  then test the same pattern twice within a single request and disagree outright. Both call sites now
+  go through one matcher that clears the stored position before testing, so the answer depends only
+  on the pattern and the path. Flags that say WHAT matches (`i`, `m`, `s`, `u`) are the consumer's
+  expressed intent and are untouched. Raised by Codex.
+
+  The clear happens only for a pattern that actually carries a position, and that guard is
+  load-bearing: `Object.freeze` on a `RegExp` — which a deep-freeze over a config module reaches —
+  makes `lastIndex` non-writable, and under ESM's strict mode assigning to it throws
+  `TypeError: Cannot assign to read only property 'lastIndex'` while `.test()` on the same pattern
+  works. Clearing unconditionally would have turned a working configuration into a throw on the
+  request path. A frozen pattern that IS global stays broken, and not by this: `test()` writes
+  `lastIndex` itself, so it throws before any of this runs.
+
+- **A second mount of `HttpAccessLogMiddleware` doubled every access-log line.** It claims the
+  request's log lifecycle so the interceptor stays silent, but never checked whether the claim was
+  already made. It now stands down on an already-claimed request: one START and one terminal entry
+  per request no matter how many times it is mounted. The claim is per-request state, so a
+  different request is unaffected.
+
+### Documentation
+
+- **`run()` now says that a nested scope DISCARDS the enclosing one.** The docblock said "a fresh
+  context scope", which does not tell a reader that an outer scope's fields are gone for the whole
+  inner one — nothing throws, `get()` just returns `undefined`, and the field is missing from every
+  entry the callback emits. Reported by a consumer that lost a `tenantId` resolved at the edge.
+
+  Replacement remains the default, and the reason is the direction the other choice leaks: a
+  background job started inside a request scope would silently inherit the caller's `userId` and
+  attribute its entries to a user who never triggered it. A missing field is visibly missing; an
+  inherited one is wrong while looking right. `runMerged()` is the explicit opt-in.
+
+- **The README states what is not logged, and what a rejected request actually produces today.** The
+  absence read as a misconfiguration to whoever went looking for it, and cost a consumer real time
+  before it was traced to the parser. The new §5 subsection carries the ordering, the two-row table
+  of what each wiring emits, and the `main.ts` snippet.
+
+- **`applyAccessLog` names `init()` as its deadline, not `listen()`.** `listen()` only triggers
+  `init()` when it has not run yet, so "before `listen()`" is true for the usual bootstrap and
+  false for a serverless entry point or an integration test that does `await app.init()` and wires
+  up afterwards — that mount lands behind the parser and logs nothing extra, with no error to say
+  so. A late mount is not rejected at runtime because NestJS exposes no supported signal for it
+  (`isInitialized` is private, and inspecting the adapter's router would break on a patch release
+  while claiming to be a safety net), so the deadline is documented at the call site instead. Raised
+  by Codex.
+
+## [1.3.1] - 2026-08-18
+
+### Documentation
+
+- **`excludePaths` says what its defaults do not reach.** The defaults are
+  `[/^\/health$/, /^\/metrics$/]`, and `@bymax-one/nest-core` serves liveness and readiness at
+  `/health/live` and `/health/ready` with no bare `/health` at all — so the default excludes a
+  route that does not exist while logging both probes. A consumer running both measured **8272 of
+  8274** HTTP entries as the liveness probe, at one container healthcheck every ten seconds; at
+  orchestrator volume it is the same shape with more zeros. There is no error and no warning, and
+  the config reads as though it were handled.
+
+  The defaults are **not** widened, and the reason is checkable rather than a preference: both
+  prefixes are configurable there (`DEFAULT_HEALTH_PATH`, `DEFAULT_METRICS_PATH`). A default
+  naming specific subpaths would be less wrong rather than correct, and a prefix pattern would
+  silently swallow a consumer's own `/health/*` route they did want logged. Excluding a path
+  decides which requests vanish from the record, so it stays explicit — the docblock now carries
+  the one-line fix for the stock layout, and it ships in the `.d.ts` where someone wiring the two
+  libraries reads it.
+
+### Internal
+
+- **The last surviving mutant is gone, by deletion rather than annotation.** A `catch` in
+  `report-destination-failure` re-assigned `undefined` to a variable already `undefined` from its
+  declaration, so emptying the block changed no output for any input and no test could kill it. A
+  Stryker directive was tried first and was not honoured at that position. The project scores
+  **100.00** on a cold run: 1515 mutants, 841 killed, zero survivors, 145 documented equivalents.
+
 ## [1.3.0] - 2026-08-18
 
 ### Fixed
@@ -1794,7 +1981,9 @@ published `dist/` is identical — no runtime behaviour changes for consumers.
 - Professional CI suite: `ci.yml`, `bench.yml`, `codeql.yml`, `scorecard.yml`,
   `release.yml`, Dependabot, and issue templates
 
-[Unreleased]: https://github.com/bymaxone/nest-logger/compare/v1.3.0...HEAD
+[Unreleased]: https://github.com/bymaxone/nest-logger/compare/v1.4.0...HEAD
+[1.4.0]: https://github.com/bymaxone/nest-logger/compare/v1.3.1...v1.4.0
+[1.3.1]: https://github.com/bymaxone/nest-logger/compare/v1.3.0...v1.3.1
 [1.3.0]: https://github.com/bymaxone/nest-logger/compare/v1.2.9...v1.3.0
 [1.2.9]: https://github.com/bymaxone/nest-logger/compare/v1.2.7...v1.2.9
 

package/README.md

@@ -301,7 +301,7 @@ Output (pretty-print, development):
 
 ### 5. HTTP logging (automatic)
 
-Enable `http.isEnabled: true` in the module options and wire `applyRequestIdMiddleware(consumer)` (see [Context propagation](#7-context-propagation-with-logcontextservice)). The access log is recorded from **middleware**, which emits:
+Enable `http.isEnabled: true` in the module options and wire the access log — `applyAccessLog(app)` in `main.ts` (recommended, see [Requests rejected before routing](#requests-rejected-before-routing)) or `applyRequestIdMiddleware(consumer)` (see [Context propagation](#7-context-propagation-with-logcontextservice)). The access log is recorded from **middleware**, which emits:
 
 | Log key                     | When                                                |
 | --------------------------- | --------------------------------------------------- |
@@ -332,6 +332,73 @@ URLs are automatically normalized — `/users/550e8400-e29b-41d4-a716-4466554400
 > A consumer who does not wire the middleware keeps the previous interceptor-based behaviour rather
 > than losing HTTP logs — including its blind spot.
 
+#### Requests rejected before routing
+
+Middleware wired through `configure(consumer)` is not early enough for every request. NestJS
+registers the body parser **one line before** it registers module middleware:
+
+```js
+// @nestjs/core/nest-application.js
+useBodyParser && this.registerParserMiddleware()
+await this.registerModules() // everything from configure(consumer)
+```
+
+Express dispatches in registration order, so when the parser rejects a body it calls `next(err)`
+and every remaining non-error handler is skipped — module middleware, guards, interceptors and the
+route handler all never run. **A `POST` carrying truncated JSON therefore produces no access log
+at all**, and the same hole covers a payload over the body limit and an unsupported content type:
+exactly the requests a client got wrong or an attacker shaped.
+
+What you get today depends on your wiring, and neither answer is good:
+
+| Wiring                                                 | A body the parser rejects produces                        |
+| ------------------------------------------------------ | --------------------------------------------------------- |
+| `forRoot` with `shouldCaptureExceptions` (the default) | **one** `HTTP_EXCEPTION_HANDLED` line, **no `requestId`** |
+| `forRootAsync`, or `shouldCaptureExceptions: false`    | **nothing at all**                                        |
+
+The first row is the one worth reading twice. The line exists, so a dashboard counting entries
+looks healthy — but the correlation scope is mounted behind the parser too, so it never opened:
+the client can send `x-request-id: measure-me` and the entry carries no `requestId` to join it to.
+A 400 you cannot trace to the caller is the same defect as a missing 400 wearing a healthier face.
+
+`applyAccessLog(app)` closes both rows. `INestApplication.use()` delegates straight to the HTTP
+adapter and `init()` (where the parser is registered) does not run until `listen()`, so mounting
+from `main.ts` lands **ahead** of the parser — the same reason `helmet` and `cookie-parser` are
+mounted this way:
+
+```typescript
+// main.ts
+import { NestFactory } from '@nestjs/core'
+import { BymaxLoggerModule, applyAccessLog } from '@bymax-one/nest-logger'
+import { AppModule } from './app.module'
+
+async function bootstrap() {
+  const app = await NestFactory.create(AppModule, { bufferLogs: true })
+  BymaxLoggerModule.useNestLogger(app)
+
+  // BEFORE the app initializes. init() is where the parser is mounted, and
+  // listen() only triggers init() when you have not called it yourself — so a
+  // serverless entry point or a test that does `await app.init()` first must
+  // mount before THAT, not merely before listen().
+  applyAccessLog(app)
+
+  await app.listen(3000)
+}
+
+void bootstrap()
+```
+
+The access log needs nothing else to work there — it emits from the response's `'close'` event,
+reading `statusCode` and `writableFinished`, so it never depends on a route matching, a handler
+running or a filter catching anything. One line in, one line out, for the parser rejection, the
+unmatched-route 404, the guard rejection and the aborted connection alike.
+
+`applyRequestIdMiddleware(consumer)` remains supported and unchanged; it is the right choice when
+correlation should be scoped to a route subtree rather than the whole application. **Wiring both is
+safe** — the correlation middleware adopts an id already in scope instead of minting a second one,
+and the access log stands down when it finds the request's lifecycle already claimed, so nothing is
+minted twice and nothing is logged twice.
+
 **Delivery is reported separately from status.** `HTTP_REQUEST_ABORTED` is emitted when the
 connection closed before the response was flushed, and it **keeps the real status the server
 produced** rather than inventing one: nginx's `499` is not an HTTP status (IANA leaves 452–499
@@ -1227,11 +1294,24 @@ There are **two** APIs on this class, and they do not share a signature shape.
 
 ### `LogContextService`
 
-| Method     | Signature           | Description                                                                                                                          |
-| ---------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| `run`      | `(store, callback)` | Opens an ALS scope. Any log inside `callback` carries `store` fields                                                                 |
-| `set`      | `(key, value)`      | Adds/updates a field in the current scope. Throws if called outside `run()`. Fields set here reach every subsequent log in the scope |
-| `getStore` | `()`                | Returns current scope or `undefined` outside a `run()` call                                                                          |
+| Method      | Signature           | Description                                                                                                                           |
+| ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| `run`       | `(store, callback)` | Opens an ALS scope. Any log inside `callback` carries `store` fields. **A nested `run()` REPLACES the enclosing context** — see below |
+| `runMerged` | `(store, callback)` | Opens a scope that EXTENDS the enclosing one: outer fields are carried in, `store` overrides them key by key                          |
+| `set`       | `(key, value)`      | Adds/updates a field in the current scope. Throws if called outside `run()`. Fields set here reach every subsequent log in the scope  |
+| `getStore`  | `()`                | Returns current scope or `undefined` outside a `run()` call                                                                           |
+
+> [!IMPORTANT]
+> **A nested `run()` discards the enclosing context.** The inner scope starts from its own `store`
+> alone, so a field an outer scope had set — a `tenantId` resolved at the edge, say — is absent for
+> the whole inner scope. Nothing throws; `get()` simply returns `undefined` and the field is missing
+> from every entry the callback emits, which is the kind of thing found by losing a field in
+> production. Use `runMerged()` when the inner scope should extend the outer one.
+>
+> Replacement stays the default because the opposite leaks in a worse direction: a background job
+> started inside a request scope would silently inherit the caller's `userId` and attribute its
+> entries to a user who never triggered it. A missing field is visibly missing; an inherited one is
+> wrong while looking right.
 
 ### Decorators
 

package/dist/server/index.cjs

@@ -768,12 +768,26 @@ var HTTP_SERVER_ERROR_MIN = 500;
 var UNKNOWN_USER_AGENT = "unknown";
 var RECORDER_ACTIVE = /* @__PURE__ */ Symbol("bymax-one/nest-logger:recorder");
 var RECORDED_ERROR = /* @__PURE__ */ Symbol("bymax-one/nest-logger:error");
+var OWN_REQUEST_ID = /* @__PURE__ */ Symbol("bymax-one/nest-logger:request-id");
+var CORRELATION_OPENED = /* @__PURE__ */ Symbol("bymax-one/nest-logger:correlation");
 function markRecorderActive(req) {
   Reflect.set(req, RECORDER_ACTIVE, true);
 }
 function isRecorderActive(req) {
   return Reflect.get(req, RECORDER_ACTIVE) === true;
 }
+function markCorrelationOpened(req) {
+  Reflect.set(req, CORRELATION_OPENED, true);
+}
+function isCorrelationOpened(req) {
+  return Reflect.get(req, CORRELATION_OPENED) === true;
+}
+function markOwnRequestId(req, requestId) {
+  Reflect.set(req, OWN_REQUEST_ID, requestId);
+}
+function readOwnRequestId(req) {
+  return Reflect.get(req, OWN_REQUEST_ID);
+}
 function recordError(req, error) {
   Reflect.set(req, RECORDED_ERROR, { error });
 }
@@ -791,6 +805,16 @@ function readUserAgent(req) {
   return typeof raw === "string" ? raw : UNKNOWN_USER_AGENT;
 }
 
+// src/server/utils/matches-exclude-path.util.ts
+function matchesExcludePath(patterns, path) {
+  return patterns.some((pattern) => {
+    if (pattern.global || pattern.sticky) {
+      pattern.lastIndex = 0;
+    }
+    return pattern.test(path);
+  });
+}
+
 // src/server/interceptors/http-logging.interceptor.ts
 var HTTP_SUCCESS_MIN = 200;
 exports.HttpLoggingInterceptor = class HttpLoggingInterceptor {
@@ -812,7 +836,7 @@ exports.HttpLoggingInterceptor = class HttpLoggingInterceptor {
    * @returns `true` when the path matches a configured exclude pattern.
    */
   isExcluded(path) {
-    return this.excludePaths.some((pattern) => pattern.test(path));
+    return matchesExcludePath(this.excludePaths, path);
   }
   /**
    * Emit the START entry, then attach success/redirect/error logging to the
@@ -1137,7 +1161,6 @@ function safeMinLevel(destination) {
     const read = destination.minLevel;
     resolved = isLogLevel(read) ? read : void 0;
   } catch {
-    resolved = void 0;
   }
   resolvedMinLevels.set(destination, resolved);
   return resolved;
@@ -2095,8 +2118,21 @@ exports.LogContextService = class LogContextService {
    * Run `callback` inside a fresh context scope. Every log emitted
    * synchronously or asynchronously within the callback inherits `context`.
    *
+   * **A nested `run()` REPLACES the enclosing context, it does not extend it.**
+   * The scope starts from `context` alone, so a field an outer scope had set —
+   * a `tenantId` resolved at the edge, say — is absent for the whole inner
+   * scope: nothing throws, `get()` simply returns `undefined`, and the field is
+   * missing from every entry the callback emits. Reach for {@link runMerged}
+   * when the inner scope should extend the outer one.
+   *
+   * Replacement is the deliberate default because the opposite leaks: a
+   * background job started inside a request scope would silently inherit the
+   * caller's `userId` and attribute its entries to a user who never triggered
+   * it. A missing field is visibly missing; an inherited one is wrong while
+   * looking right.
+   *
    * @typeParam T - Return type of the callback.
-   * @param context - Initial context bag for the scope.
+   * @param context - Initial context bag for the scope. Becomes the WHOLE scope.
    * @param callback - Function executed within the scope.
    * @returns Whatever `callback` returns.
    * @example
@@ -2107,6 +2143,35 @@ exports.LogContextService = class LogContextService {
   run(context, callback) {
     return this.als.run(this.sanitizeContext(context), callback);
   }
+  /**
+   * Run `callback` inside a scope that EXTENDS the enclosing one: the active
+   * context's fields are carried in, and `context` overrides them key by key.
+   *
+   * The explicit counterpart to {@link run}'s replacement semantics, for the
+   * case where an inner scope is genuinely a refinement of the outer — adding a
+   * `userId` once authentication resolved it, without having to restate the
+   * `requestId` the middleware already set.
+   *
+   * Outside any scope there is nothing to merge and this behaves exactly like
+   * {@link run}. Writes inside the new scope never reach the enclosing one: the
+   * merge produces a fresh object, so the outer context is intact after the
+   * callback returns.
+   *
+   * @typeParam T - Return type of the callback.
+   * @param context - Fields to add or override on top of the active context.
+   * @param callback - Function executed within the merged scope.
+   * @returns Whatever `callback` returns.
+   * @example
+   *   logContext.run({ requestId: 'r_1' }, () => {
+   *     logContext.runMerged({ userId: 'u_1' }, () => {
+   *       logContext.get('requestId') // 'r_1' — carried in from the outer scope
+   *     })
+   *   })
+   */
+  runMerged(context, callback) {
+    const merged = { ...this.als.getStore(), ...this.sanitizeContext(context) };
+    return this.als.run(merged, callback);
+  }
   /**
    * Read the active context, or `undefined` when called outside any scope.
    *
@@ -2538,7 +2603,7 @@ var PrettyDevDestination = class {
     });
   }
 };
-var HttpAccessLogMiddleware = class {
+exports.HttpAccessLogMiddleware = class HttpAccessLogMiddleware {
   /**
    * @param logger - The structured logger the access entries are written to.
    *   Injected by token explicitly: the package is bundled without
@@ -2559,13 +2624,17 @@ var HttpAccessLogMiddleware = class {
    * @param next - The next handler in the chain.
    */
   use(req, res, next) {
+    if (isRecorderActive(req)) {
+      next();
+      return;
+    }
     if (!this.isEnabled) {
       next();
       return;
     }
     const target = req.originalUrl ?? req.url;
     const path = stripQueryString(target);
-    if (this.excludePaths.some((pattern) => pattern.test(path))) {
+    if (matchesExcludePath(this.excludePaths, path)) {
       next();
       return;
     }
@@ -2652,15 +2721,16 @@ var HttpAccessLogMiddleware = class {
     );
   }
 };
-HttpAccessLogMiddleware = __decorateClass([
+exports.HttpAccessLogMiddleware = __decorateClass([
   common.Injectable(),
   __decorateParam(0, common.Inject(exports.PinoLoggerService)),
   __decorateParam(1, common.Inject(exports.LogContextService)),
   __decorateParam(2, common.Inject(LOGGER_OPTIONS_TOKEN))
-], HttpAccessLogMiddleware);
+], exports.HttpAccessLogMiddleware);
 var REQUEST_ID_HEADER = "x-request-id";
 var MAX_CORRELATION_ID_LENGTH = 256;
 var CORRELATION_ID_CHARSET = /^[A-Za-z0-9._:/+=-]+$/;
+var INHERITABLE_CONTEXT_KEYS = ["requestId", "tenantId"];
 function isAcceptableHeaderValue(value) {
   return typeof value === "string" && value.length <= MAX_CORRELATION_ID_LENGTH && CORRELATION_ID_CHARSET.test(value);
 }
@@ -2679,27 +2749,128 @@ exports.RequestIdMiddleware = class RequestIdMiddleware {
   }
   /**
    * Echo or mint the `x-request-id`, expose it on the response, and run the
-   * remainder of the request inside a fresh log-context scope.
+   * remainder of the request inside its own log-context scope.
+   *
+   * Idempotent: mounting this middleware twice on the same request mints one id,
+   * not two. The request gets its OWN store, started from the enclosing scope's
+   * correlation fields — see {@link INHERITABLE_CONTEXT_KEYS} — and nothing
+   * else, because no other field can be known to belong to this request.
+   *
+   * An enclosing scope's `requestId` is never adopted and never echoed: adoption
+   * reads a value this middleware recorded on the REQUEST, which a scope opened
+   * elsewhere does not have. What the two generation modes do with one, measured
+   * on two requests sharing a long-lived enclosing scope:
+   *
+   *   - `shouldGenerateRequestId: true` (default) — each request mints its own
+   *     id, the two requests differ, and the enclosing value reaches neither the
+   *     header nor the entries.
+   *   - `shouldGenerateRequestId: false` with no inbound header — nothing is
+   *     minted, so the request scope inherits the enclosing `requestId` and every
+   *     request inside that scope logs under it. No header is exposed. That is
+   *     the consumer's own scope being inherited, not correlation being reused,
+   *     and it is the configuration that says the gateway owns the id.
    *
    * @param req - The incoming request (Express satisfies the contract).
    * @param res - The outgoing response (Express satisfies the contract).
    * @param next - The next handler in the chain.
    */
   use(req, res, next) {
-    const incoming = Reflect.get(req.headers, REQUEST_ID_HEADER);
-    const fromHeader = isAcceptableHeaderValue(incoming) ? incoming : void 0;
-    const requestId = fromHeader ?? (this.shouldGenerateRequestId ? crypto.randomUUID() : void 0);
-    const context = {};
+    if (isCorrelationOpened(req)) {
+      const ownRequestId = readOwnRequestId(req);
+      if (ownRequestId !== void 0) {
+        this.adoptExistingScope(ownRequestId, req, res);
+      }
+      next();
+      return;
+    }
+    markCorrelationOpened(req);
+    const context = this.inheritableContext();
+    const requestId = this.resolveRequestId(req);
     if (requestId !== void 0) {
       res.setHeader(REQUEST_ID_HEADER, requestId);
       context.requestId = requestId;
+      markOwnRequestId(req, requestId);
     }
-    const rawTenantId = Reflect.get(req.headers, this.tenantIdHeader);
-    if (isAcceptableHeaderValue(rawTenantId)) {
-      context.tenantId = rawTenantId;
+    if (context.tenantId === void 0) {
+      const tenantId = this.resolveTenantId(req);
+      if (tenantId !== void 0) {
+        context.tenantId = tenantId;
+      }
     }
     this.logContext.run(context, () => next());
   }
+  /**
+   * The enclosing scope's fields that a request scope may start from.
+   *
+   * Plain `run()` would discard everything the caller had set and a plain merge
+   * would carry identity across requests; {@link INHERITABLE_CONTEXT_KEYS} is
+   * the middle a request scope actually needs.
+   *
+   * @returns A fresh bag, never the enclosing store itself, so writes inside the
+   *   request never reach the scope that opened it.
+   */
+  inheritableContext() {
+    const store = { ...this.logContext.getStore() };
+    const inherited = {};
+    for (const key of INHERITABLE_CONTEXT_KEYS) {
+      const value = Reflect.get(store, key);
+      if (value !== void 0) {
+        Reflect.set(inherited, key, value);
+      }
+    }
+    return inherited;
+  }
+  /**
+   * Second mount on a request that already carries a correlation id: echo the id
+   * onto the response and fill in a tenant the scope does not have yet, without
+   * opening another scope.
+   *
+   * Nothing is minted and nothing already set is overwritten, so a third mount —
+   * or a thirtieth — changes nothing. The response header is written on every
+   * pass because the enclosing scope may have been opened by consumer code that
+   * never exposed it.
+   *
+   * @param requestId - The id already in scope, which wins.
+   * @param req - The incoming request, read for the tenant header.
+   * @param res - The outgoing response, where the effective id is exposed.
+   */
+  adoptExistingScope(requestId, req, res) {
+    res.setHeader(REQUEST_ID_HEADER, requestId);
+    this.logContext.set("requestId", requestId);
+    if (this.logContext.get("tenantId") === void 0) {
+      const tenantId = this.resolveTenantId(req);
+      if (tenantId !== void 0) {
+        this.logContext.set("tenantId", tenantId);
+      }
+    }
+  }
+  /**
+   * The correlation id for this request: the inbound header when acceptable,
+   * otherwise a fresh UUID — or nothing at all when `shouldGenerateRequestId` is
+   * off and the caller sent none, which leaves correlation to the upstream
+   * gateway.
+   *
+   * @param req - The incoming request.
+   * @returns The id, or `undefined` when none is available and none is minted.
+   */
+  resolveRequestId(req) {
+    const incoming = Reflect.get(req.headers, REQUEST_ID_HEADER);
+    const fromHeader = isAcceptableHeaderValue(incoming) ? incoming : void 0;
+    return fromHeader ?? (this.shouldGenerateRequestId ? crypto.randomUUID() : void 0);
+  }
+  /**
+   * The tenant id carried by the configured header, when it is acceptable.
+   *
+   * Never minted: a tenant is an assertion about who the request belongs to, and
+   * inventing one would be a fabricated claim rather than a correlation aid.
+   *
+   * @param req - The incoming request.
+   * @returns The tenant id, or `undefined`.
+   */
+  resolveTenantId(req) {
+    const raw = Reflect.get(req.headers, this.tenantIdHeader);
+    return isAcceptableHeaderValue(raw) ? raw : void 0;
+  }
 };
 exports.RequestIdMiddleware = __decorateClass([
   common.Injectable(),
@@ -2707,10 +2878,36 @@ exports.RequestIdMiddleware = __decorateClass([
   __decorateParam(1, common.Inject(LOGGER_OPTIONS_TOKEN))
 ], exports.RequestIdMiddleware);
 
+// src/server/middlewares/apply-access-log.ts
+function resolveDependencies(app) {
+  try {
+    return {
+      logger: app.get(exports.PinoLoggerService),
+      logContext: app.get(exports.LogContextService),
+      options: app.get(LOGGER_OPTIONS_TOKEN)
+    };
+  } catch (cause) {
+    throw new Error(
+      "[BymaxLoggerModule] applyAccessLog(app) called but BymaxLoggerModule was not imported",
+      { cause }
+    );
+  }
+}
+function applyAccessLog(app) {
+  const { logger, logContext, options } = resolveDependencies(app);
+  const requestId = new exports.RequestIdMiddleware(logContext, options);
+  const accessLog = new exports.HttpAccessLogMiddleware(logger, logContext, options);
+  app.use((req, res, next) => {
+    requestId.use(req, res, () => {
+      accessLog.use(req, res, next);
+    });
+  });
+}
+
 // src/server/middlewares/apply-request-id-middleware.ts
 var ALL_ROUTES = "/";
 function applyRequestIdMiddleware(consumer, routes = ALL_ROUTES) {
-  consumer.apply(exports.RequestIdMiddleware, HttpAccessLogMiddleware).forRoutes(routes);
+  consumer.apply(exports.RequestIdMiddleware, exports.HttpAccessLogMiddleware).forRoutes(routes);
 }
 var INJECT_LOGGER_CONTEXT_METADATA_KEY = "bymax_logger:context";
 function InjectLogger(context) {
@@ -2788,4 +2985,5 @@ exports.PINO_LEVEL_NUMBERS = PINO_LEVEL_NUMBERS;
 exports.PrettyDevDestination = PrettyDevDestination;
 exports.RESERVED_LOG_KEYS = RESERVED_LOG_KEYS;
 exports.RESERVED_LOG_KEYS_NOT_EMITTED = RESERVED_LOG_KEYS_NOT_EMITTED;
+exports.applyAccessLog = applyAccessLog;
 exports.applyRequestIdMiddleware = applyRequestIdMiddleware;