fix: don't render test's own trace as Linked Trace in HTML report

[thomhurst]

Summary

• Engine auto-registers test's own traceId in TraceRegistry (for OTLP cross-process log correlation). HtmlReporter then read that same ID back as an "additional" trace, so the primary trace rendered twice — once as Trace Timeline (descendants of the test case span, flattens test body) and once as Linked Trace: TUnit (raw full trace, includes test body). Near-duplicate with a subtle difference, confusing for users.
• Added HtmlReporter.FilterAdditionalTraceIds to strip the primary traceId from the TraceRegistry.GetTraceIds result. Linked Traces now appear only when the user calls TestContext.RegisterTrace with a genuinely different trace, matching the documented behavior in docs/docs/guides/html-report.md.

Test plan

• New unit tests in HtmlReporterTests cover: case-insensitive match, null primary, no match (returns same array), only primary (returns empty).
• All 9 HtmlReporterTests pass (4 new + 5 existing).

[claude]

Code Review

Summary

Clean, well-scoped fix for a real UX bug. The implementation is correct and the test coverage is thorough.

---

What's Good

• Early-exit optimization (allTraceIds.Length == 0 || primaryTraceId is null) avoids unnecessary work in the common case.
• Reference preservation (filtered.Count == allTraceIds.Length ? allTraceIds : filtered.ToArray()) is a nice touch — the ShouldBeSameAs tests validate this contract, confirming no allocation when filtering is a no-op.
• Case-insensitive comparison (StringComparison.OrdinalIgnoreCase) is the right choice for hex trace IDs that may arrive in different casing from different OTLP exporters.
• internal static makes the method unit-testable without leaking it as public API.
• Test coverage hits all four meaningful branches: primary null, no match, match-only, and case-insensitive match.
• The #if NET guard is consistent with the surrounding context.

---

Architectural Observation (non-blocking)

The fix is applied at the consumer side (HtmlReporter), filtering out a trace ID that the engine registered on the producer side (TraceRegistry) for a different purpose (OTLP cross-process correlation). This is pragmatic and avoids breaking OTLP, but it means any future reporter that reads TraceRegistry.GetTraceIds would have the same bug and need the same filter.

A more robust long-term approach would be to have TraceRegistry natively distinguish between primary and user-registered traces, exposing something like GetAdditionalTraceIds(testId, excludePrimary). That way the filtering logic lives once, at the data layer, and reporters get correct data by default.

That said, given this is a focused bug fix and the current reporter count is one, the current approach is a reasonable tradeoff. Worth keeping in mind if a second reporter is ever added.

---

Minor

The multi-line comment explaining why the filter exists is appropriate here — the reason is genuinely non-obvious (engine auto-registration for OTLP), and a future reader would be confused without it. Good call including it.

---

Verdict: Approved. The fix is correct, well-tested, and the tradeoff is understood. The architectural note above is a future consideration, not a blocker.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 9 complexity

Metric	Results
Complexity	9

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}