QuickApps version
latest
What is the problem this feature will solve?
Log records carry no request identity unless OTEL log correlation is enabled (off by default) — concurrent requests interleave without a way to tell them apart, and the lifecycle events from #435 can't be stitched into one request's story. The existing error_reference appears only in the final exception handler, not on the records leading up to it.
What is the feature you are proposing to solve the problem?
Ambient request-scoped context (request id, app/deployment id) stamped on every record emitted during a request, independent of OTEL, rendered in both text and JSON output; extend the error_reference idea so one reference finds all of a request's records.
What alternatives have you considered?
Relying on OTEL trace correlation alone — investigation should work from plain logs without a tracing backend. Passing ids into individual log calls — unenforceable across ~90 logging modules; enrichment must be ambient.
Additional information
After #438 (field-naming contract) and #435 (the events these fields decorate). The existing OtelAwareFormatter shows the pattern for conditionally rendered context.
With #438 re-scoped to adopting aidial-sdk 0.38.0 structured logging, two constraints from the SDK's formatters apply here:
- The SDK JSON formatter auto-adds only
otel* record fields, so the request-context fields must be referenced explicitly in the shipped JSON template (a missing field renders as an empty string, keeping out-of-request records safe).
- The SDK text formatter drops any record whose format string references a missing field, so ambient stamping must guarantee the context fields exist on every record — including ones emitted outside any request.
Field names should extend the SDK's default vocabulary (level, time, logger, process, message, otel*) rather than define a parallel contract.
QuickApps version
latest
What is the problem this feature will solve?
Log records carry no request identity unless OTEL log correlation is enabled (off by default) — concurrent requests interleave without a way to tell them apart, and the lifecycle events from #435 can't be stitched into one request's story. The existing
error_referenceappears only in the final exception handler, not on the records leading up to it.What is the feature you are proposing to solve the problem?
Ambient request-scoped context (request id, app/deployment id) stamped on every record emitted during a request, independent of OTEL, rendered in both text and JSON output; extend the
error_referenceidea so one reference finds all of a request's records.What alternatives have you considered?
Relying on OTEL trace correlation alone — investigation should work from plain logs without a tracing backend. Passing ids into individual log calls — unenforceable across ~90 logging modules; enrichment must be ambient.
Additional information
After #438 (field-naming contract) and #435 (the events these fields decorate). The existing
OtelAwareFormattershows the pattern for conditionally rendered context.With #438 re-scoped to adopting aidial-sdk 0.38.0 structured logging, two constraints from the SDK's formatters apply here:
otel*record fields, so the request-context fields must be referenced explicitly in the shipped JSON template (a missing field renders as an empty string, keeping out-of-request records safe).Field names should extend the SDK's default vocabulary (
level,time,logger,process,message,otel*) rather than define a parallel contract.