@bymax-one/nest-logger 1.3.1 → 1.4.1

package/CHANGELOG.md

@@ -11,6 +11,210 @@ heading here.
 
 ## [Unreleased]
 
+## [1.4.1] - 2026-10-23
+
+No breaking changes.
+
+### Added
+
+- **`PinoUnexpectedErrorSink` — the cause of a nest-core `500`, logged.** When nest-core's exception
+  filter turns an unexpected error into `500 BYMAX_INTERNAL_ERROR`, the access-log line carries the
+  cause only when this package's HTTP interceptor saw the error. An error raised before it (in a
+  guard or a middleware), or any error with HTTP logging off, left a synthetic
+  `Error("GET /url → 500")` or no line at all. nest-core 1.6.2 adds an
+  optional `BYMAX_UNEXPECTED_ERROR_SINK` token. This class implements it: one `error` entry per
+  unexpected error, keyed `HTTP_UNEXPECTED_ERROR`, with the original error's type, message, stack
+  and cause chain, plus `method`, the route template (`route`, never the raw URL) and
+  `correlationId`. It adds nothing else from the request — no body, headers or query string — and
+  `record()` never throws. The error keeps its own enumerable fields, as on every `err` entry, so
+  request data an error object carries itself is logged under the usual key-name redaction.
+
+  This package still does not depend on nest-core. The class matches nest-core's contract by
+  shape, and the types it implements are exported as `IUnexpectedErrorSink` and
+  `UnexpectedErrorReport`.
+
+  `HTTP_UNEXPECTED_ERROR` joins `RESERVED_LOG_KEYS`. An application that already writes that key
+  for its own events should rename them, or its queries will mix the two.
+
+#### Apply to a derived backend
+
+Requires `@bymax-one/nest-core` 1.6.2 or later. Nothing changes until you bind the sink: the token
+is optional and unbound by default. Bind it from a `@Global()` module imported next to
+`BymaxLoggerModule`:
+
+```typescript
+@Global()
+@Module({
+  providers: [{ provide: BYMAX_UNEXPECTED_ERROR_SINK, useClass: PinoUnexpectedErrorSink }],
+  exports: [BYMAX_UNEXPECTED_ERROR_SINK]
+})
+export class UnexpectedErrorSinkModule {}
+```
+
+`BYMAX_UNEXPECTED_ERROR_SINK` comes from `@bymax-one/nest-core` and `PinoUnexpectedErrorSink` from
+`@bymax-one/nest-logger`. To verify, make a route throw a plain `Error`: the response stays
+`500 BYMAX_INTERNAL_ERROR`, and the log gains one `HTTP_UNEXPECTED_ERROR` line next to the
+access-log line.
+
+## [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
@@ -1822,7 +2026,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.1...HEAD
+[Unreleased]: https://github.com/bymaxone/nest-logger/compare/v1.4.1...HEAD
+[1.4.1]: https://github.com/bymaxone/nest-logger/compare/v1.4.0...v1.4.1
+[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
@@ -344,6 +411,48 @@ flushed** is reported as the success it was — the server completed and flushed
 peer read it is not knowable from the server side. What this catches is the case that matters
 operationally: the slow upstream, the load-balancer timeout, the cancelled request.
 
+#### Unexpected errors behind `@bymax-one/nest-core`
+
+When nest-core's exception filter answers, an unexpected error becomes a fixed
+`500 BYMAX_INTERNAL_ERROR`. The access-log line for that response carries the cause only when this
+package's HTTP interceptor saw the error, which it does not for an error raised before it (in a
+guard or a middleware) or with HTTP logging off. nest-core 1.6.2 adds an optional sink token, `BYMAX_UNEXPECTED_ERROR_SINK`, and
+`PinoUnexpectedErrorSink` is a ready implementation of it. Bind it from a global module:
+
+```typescript
+import { Global, Module } from '@nestjs/common'
+import { BYMAX_UNEXPECTED_ERROR_SINK } from '@bymax-one/nest-core'
+import { PinoUnexpectedErrorSink } from '@bymax-one/nest-logger'
+
+@Global()
+@Module({
+  providers: [{ provide: BYMAX_UNEXPECTED_ERROR_SINK, useClass: PinoUnexpectedErrorSink }],
+  exports: [BYMAX_UNEXPECTED_ERROR_SINK]
+})
+export class UnexpectedErrorSinkModule {}
+```
+
+Import it next to `BymaxLoggerModule`. The binding resolves `PinoLoggerService` because
+`BymaxLoggerModule` is global by default; with `isGlobal: false`, add the same `forRoot`/`forRootAsync` result the
+application imports to the sink module's `imports`. Keep it in a constant: calling `forRoot` a
+second time builds a second logger. Each unexpected error then produces one `error` entry with the key
+`HTTP_UNEXPECTED_ERROR`:
+
+| Field           | Content                                                                                                 |
+| --------------- | ------------------------------------------------------------------------------------------------------- |
+| `err`           | The original error through the `err` serializer: type, message, scrubbed stack, cause chain, own fields |
+| `method`        | HTTP method                                                                                             |
+| `route`         | Matched route template (`/invoices/:id`), or `<unmatched>` before routing — never the raw URL           |
+| `correlationId` | nest-core's correlation id, when one resolved                                                           |
+
+The sink adds nothing from the request beyond `method`, `route` and `correlationId`: no body,
+headers or query string. The error is serialized as on every `err` entry, own enumerable fields
+included, so an error object that itself carries request data (a `url` with a query string, a copy
+of the headers) brings that data along, under the same key-name redaction. The trace id comes from the trace mixin, as on every other entry. `record()`
+never throws, so a failing destination cannot change the response. This package does not import
+nest-core: the class matches nest-core's contract by shape, and `IUnexpectedErrorSink` /
+`UnexpectedErrorReport` are exported for reference.
+
 ### 6. OpenTelemetry correlation
 
 Initialize the OTel SDK **before** importing NestJS — this is critical:
@@ -662,7 +771,7 @@ function assertValidLogKey(key: string) {
 
 The following keys are used internally by the library — do not reuse them in application code:
 
-`LOGGER_BOOTSTRAP_OK` · `LOGGER_BOOTSTRAP_WARNING` · `LOGGER_SHUTDOWN_OK` · `HTTP_REQUEST_START` · `HTTP_REQUEST_SUCCESS` · `HTTP_REQUEST_REDIRECT` · `HTTP_REQUEST_CLIENT_ERROR` · `HTTP_REQUEST_SERVER_ERROR` · `HTTP_REQUEST_ABORTED` · `HTTP_REQUEST_COMPLETED` · `HTTP_EXCEPTION_HANDLED` · `HTTP_EXCEPTION_UNHANDLED` · `METHOD_EXECUTION` · `METHOD_SLOW_EXECUTION` · `LOGGER_DESTINATION_INIT_FAILED` · `LOGGER_DESTINATION_WRITE_FAILED` · `LOGGER_ENTRY_TRUNCATED` · `LOGGER_REDACTION_FAILED`
+`LOGGER_BOOTSTRAP_OK` · `LOGGER_BOOTSTRAP_WARNING` · `LOGGER_SHUTDOWN_OK` · `HTTP_REQUEST_START` · `HTTP_REQUEST_SUCCESS` · `HTTP_REQUEST_REDIRECT` · `HTTP_REQUEST_CLIENT_ERROR` · `HTTP_REQUEST_SERVER_ERROR` · `HTTP_REQUEST_ABORTED` · `HTTP_REQUEST_COMPLETED` · `HTTP_EXCEPTION_HANDLED` · `HTTP_EXCEPTION_UNHANDLED` · `HTTP_UNEXPECTED_ERROR` · `METHOD_EXECUTION` · `METHOD_SLOW_EXECUTION` · `LOGGER_DESTINATION_INIT_FAILED` · `LOGGER_DESTINATION_WRITE_FAILED` · `LOGGER_ENTRY_TRUNCATED` · `LOGGER_REDACTION_FAILED`
 
 All reserved keys are exported as the `RESERVED_LOG_KEYS` constant from `@bymax-one/nest-logger/shared`.
 
@@ -1227,11 +1336,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