Repository navigation
Improve debugger trace detail for federation failures #902
Description
Why
The debugger trace detail page already shows activity records, signature status, Activity JSON, and logs. That is a good base, but it is still hard to answer the common debugging question: why did this ActivityPub request fail?
When a trace has signature failures, delivery errors, or background processing logs, maintainers need the relevant span attributes and logs close together instead of switching between raw JSON, a log table, and source code.
Current code
The detail page is rendered by packages/debugger/src/views/trace-detail.tsx. Logs are stored by packages/debugger/src/log-store.ts. The debugger app and tests are in packages/debugger/src/mod.tsx and packages/debugger/src/mod.test.ts.
The current page groups by activity, then shows a separate log table for the whole trace.
Scope
Improve the trace detail page so failures are easier to scan. A good implementation would:
- show error or warning logs near the activity or span they belong to when
spanIdis available; - surface relevant span attributes such as
activitypub.object.id,activitypub.activity.type, HTTP status, inbox URL, signature key ID, and signature algorithm when they are present in exported trace records; - keep the full log table available for trace-level context;
- handle traces with malformed timestamps or missing optional fields without throwing.
#1257 owns the federation instrumentation and typed record data needed to persist failed outbound delivery attempts. This issue owns debugger log spanId persistence and rendering, including delivery outcome labels and attempt grouping. Other small typed extensions needed to expose existing trace data remain in scope here.
Non-goals
Do not redesign the debugger. Do not add a new storage backend. Do not duplicate the filtering work from #896.
Suggested checks
Add rendering tests in packages/debugger/src/mod.test.ts or focused component tests if that is the local pattern. Include a trace with one failed activity, one related error log, and one unrelated log in the same trace.
Prerequisites
#1030 aligns federation logs with their operation spans. #1257 adds records for failed outbound attempts, which currently have no TraceActivityRecord. Completing the failed outbound delivery display requires the logging alignment from #1205 and the failure records from #1257.
Log spanId persistence, correlation with existing records, and display of logs without matching records can proceed independently. Completing the outbound failure display requires real failed-delivery records from #1257; manually matched rendering fixtures alone do not establish that correlation.
Activity
u-zzn commentedon Sep 13, 2026
Hi! I'm Yujin, an OSSCA 2026 mentee, and I'm interested in working on this issue.
I took a look through the debugger and federation code before getting started, and I had one question about the intended scope.
From what I understand,
TraceActivityRecord.spanIdcomes from the span created for the individual federation operation, while thespanIdattached to LogTape records appears to come from the surrounding logging context. SincewithContext()is currently set at a broader request/queue-worker level, it seems like these IDs may not always match for cases such as delivery failures.Would the intended scope of this issue be to improve the debugger using the correlation data that is currently available, or should it also include aligning the logging context with the individual activity spans in the federation layer?
If the former is within scope, I'd be happy to take this issue and work on it. Thanks!
dahlia commentedon Sep 13, 2026
Thanks for looking into this, @u-zzn. The span ID mismatch you identified needs to be fixed so #902 can reliably show logs beside the activity they belong to.
I've opened #1030 to align the logging context with the individual federation spans and marked it as blocking #902. The federation changes will be handled in #1030, while #902 will stay focused on the debugger improvements you expressed interest in.
Some debugger work could start independently, but checking that logs appear beside the correct activity will need to wait until #1030 is resolved. Would you still be interested in working on #902 once that prerequisite is resolved?
u-zzn commentedon Sep 13, 2026
Thanks for clarifying and for creating #1030!
Yes, I'm still interested in working on #902. Since #1030 came out of the issue I noticed while looking into the tracing flow, I'm also interested in understanding and potentially working on #1030 as well.
I realize that #1030 involves deeper federation and OpenTelemetry context handling, so before taking it on, I'd like to ask whether you think it would be reasonable for me to work on #1030 as well, or whether you'd prefer that I stay focused on #902 for now.
dahlia commentedon Sep 13, 2026
Yes, you're welcome to work on #1030 as well! I think having the same person work on both issues would help, since you could keep track of how the federation logging changes and debugger improvements fit together.
If you'd like to take on #1030, please leave a comment on that issue so I can assign it to you. You can start there and then move on to #902.