Background
#902 aims to show warning and error logs beside the activity they belong to. As @u-zzn noted in #902, activity records and logs can carry different span IDs for the same operation.
TraceActivityRecord.spanId identifies the individual federation operation, while LogTape's spanId comes from the logging context established with withContext(). That context is currently set at the broader HTTP request or queue-worker level. A delivery operation can therefore create its own span while its failure logs still carry the enclosing worker's span ID. Matching logs to activity records by spanId would miss those failures.
This issue covers the federation instrumentation needed by #902. Completion of this work is a prerequisite for verifying the log-to-activity correlation in #902.
Scope
Align the LogTape context with the individual federation spans represented by activity records, including outbound delivery and inbound activity processing.
- Ensure logs emitted within an activity operation carry that operation's
traceId and spanId.
- Restore the enclosing logging context when the operation finishes or throws, and keep concurrent operations' contexts separate.
- Keep logs from the enclosing request or worker associated with that enclosing span.
- Preserve existing logging context properties, such as request and message IDs.
#902 covers debugger log persistence and rendering, including preserving spanId when serializing logs and displaying related warnings and errors. This issue does not require changing the trace hierarchy or redesigning logging across Fedify.
Validation
Add regression tests that exercise federation operations and capture the logs they actually emit. Include a delivery failure inside a queue worker and an inbound processing failure; verify that each relevant log has the same traceId and spanId as its activity record. Check context restoration on success and failure, and isolation between concurrent operations. Rendering tests with manually matched IDs are not sufficient to verify this behavior.
Background
#902 aims to show warning and error logs beside the activity they belong to. As @u-zzn noted in #902, activity records and logs can carry different span IDs for the same operation.
TraceActivityRecord.spanIdidentifies the individual federation operation, while LogTape'sspanIdcomes from the logging context established withwithContext(). That context is currently set at the broader HTTP request or queue-worker level. A delivery operation can therefore create its own span while its failure logs still carry the enclosing worker's span ID. Matching logs to activity records byspanIdwould miss those failures.This issue covers the federation instrumentation needed by #902. Completion of this work is a prerequisite for verifying the log-to-activity correlation in #902.
Scope
Align the LogTape context with the individual federation spans represented by activity records, including outbound delivery and inbound activity processing.
traceIdandspanId.#902 covers debugger log persistence and rendering, including preserving
spanIdwhen serializing logs and displaying related warnings and errors. This issue does not require changing the trace hierarchy or redesigning logging across Fedify.Validation
Add regression tests that exercise federation operations and capture the logs they actually emit. Include a delivery failure inside a queue worker and an inbound processing failure; verify that each relevant log has the same
traceIdandspanIdas its activity record. Check context restoration on success and failure, and isolation between concurrent operations. Rendering tests with manually matched IDs are not sufficient to verify this behavior.