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
spanId is 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.
If the current TraceActivityRecord shape does not expose enough data, add the smallest typed extension needed in the Fedify OTel code and update the debugger tests around it.
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.
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:
spanIdis available;activitypub.object.id,activitypub.activity.type, HTTP status, inbox URL, signature key ID, and signature algorithm when they are present in exported trace records;If the current
TraceActivityRecordshape does not expose enough data, add the smallest typed extension needed in the Fedify OTel code and update the debugger tests around it.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.