Give the Logs tab back its log on the default reader (fixes #480) - #482

Fixes #480.

The Logs tab on the default reader opened on four section titles and nothing else. It failed in the way that is hardest to notice: the tab loads, the iframe returns 200, nothing warns — the page just says almost nothing. The same bundle read with --result-reader modern had the whole log all along, so what a user saw depended on a flag most of them never pass. And it would have self-repaired the day Apple removes --legacy, taking the evidence with it.

Root cause

The legacy log document is a polymorphic tree — ActivityLogSection, ActivityLogUnitTestSection, ActivityLogCommandInvocationSection — and the log text is each node's messages[]. Content was lost at two independent points.

1. A decode-time type filter. XCResultFile.getLogs(id:) returns ActivityLogSection, whose children XCResultKit decodes as xcArray(element: "subsections", from: json).ofType(ActivityLogSection.self), and ofType keeps only elements whose _type._name matches exactly. Every subtyped child was discarded before any code of ours ran. On TestResults that is both Test target … branches at the root and every Install Actions / Launch … leaf. Not fixable from outside the library, and getRootJson is not public at the pinned version.

2. A formatter written for the wrong shape. ActivityLogSection.formatEmittedOutput() emitted title plus its subsections and nothing else. That type has no emittedOutput at all — the property is declared on the ActivityLogUnitTestSection subtype — so the content the surviving nodes did carry, messages[], was never read. The sibling ActivityLogUnitTestSection: EmittableOutput conformance that concatenates emittedOutput was unreachable: getLogs is typed to the base class and subsections is [ActivityLogSection], so Swift statically dispatched the base implementation at every level. It was dead code, which is why nobody noticed it read a field the live path never saw.

Four titles survive both filters. That is the husk, exactly.

It is not the mirror image of the modern gap

The task asked whether legacy has the inverse of modern's "publishes emittedOutput, never populates it, content in messages[]". It does not. Dumping both documents for one bundle shows they describe a node-for-node identical tree with identical messages[]; modern leaves emittedOutput null throughout, and legacy populates it on its unit-test nodes. So messages[] is the log on both sides, and reading it makes the two exports byte-identical rather than merely comparable.

Legacy's emittedOutput (9.6 KB on TestResults) is deliberately not exported, and this is not masking — none of it was ever in the legacy export to begin with. It is the per-row console popover in Xcode, not its Log view: Xcode's own All Messages renders titles and messages, which is precisely what both readers now emit. It also nests cumulatively — a parent repeats every descendant's text, so emitting it per node would multiply the file with duplicates — and the modern format has no counterpart, so exporting it would buy legacy-only content at the price of a permanent, allow-listed divergence in the reader that is on its way out. RunLogSection's doc comment records that reasoning where the next reader will find it.

The fix

One shape, one formatter, two decoders:

• RunLogSection — title, messages, children — plus formatted(), the layout Xcode's Log view uses. This is now the only place either backend renders a log.
• LegacyRunLogDocument decodes xcresulttool get --legacy --format json directly, reading the fields every node shares and ignoring _type entirely. That fixes defect 1 and makes the reader indifferent to a node type Apple adds later: an unrecognised subtype keeps its title, messages and children instead of vanishing.
• LogSection.runLogSection maps the modern document into the same shape. Its output is unchanged byte for byte — the formatter moved, it did not change.
• EmittableOutput is deleted. Those two conformances were its only users.
• XCResultToolInvoking gains runUnversioned, which omits the pinned --schema-version: get --legacy does not advertise that flag, since the legacy document carries its own _type envelope instead of a versioned schema. A protocol-extension default forwards to run, so the existing test fakes are untouched.

Before / after

Same TestResults.xcresult, same binary, only --result-reader differs:

cmp reports the two exports byte-identical.

The blind spot, closed

DifferentialTests compared the rendered index.html and the attachment filenames and bytes. The log payload is neither — and the iframe src is a digest of the run rather than of its content, so it is byte-identical on both sides whatever the file behind it says. A 56× content difference passed as parity.

testExportedRunLogsAreIdenticalAcrossBackends now renders each fixture inline through both readers and requires the exported log bytes to be equal, run by run, across all three fixtures — the same treatment testAttachmentPayloadsAreByteIdenticalAcrossBackends gives attachments. It asserts run counts before zipping, and it is non-vacuous: equality alone would pass on two empty logs, or on two logs that are nothing but structure, so it also requires each legacy log to carry a line that is not a -------- title -------- header. Every line the shared formatter emits is either a header or a message, so that is a direct assertion that the messages are there — which is the thing both backends would have to keep losing for this to regress. No allow-list entry: the two backends agree exactly, so there is nothing to declare.

RunLogTests pins the two losses on documents small enough to read — that a subtyped child survives decoding, that messages is read with shortTitle as the fallback, the formatter's layout, and that both decoders reduce the same log to the same text.

It lives in DifferentialLogTests.swift for the reason DifferentialSummaryHeaderTests.swift does: DifferentialTests is at its length limit, and the extension shares its cached summaries. Inline summaries are now cached the way the linking ones already were, so the new assertion adds no xcresulttool subprocess time.

Fault discipline: should the husk have faulted?

No, and a size threshold would have been the wrong instrument. Recorded here because the question is worth answering explicitly.

The husk was not a read failure. getLogs returned a decoded document, the write succeeded, every subprocess exited 0. The fault vocabulary names a cause (logExportFailed) and a symptom (unresolvedLog), and neither was true: content was read and content was written. The loss happened between them, inside the formatter — a correctness bug, not degradation.

Detecting "genuinely read but implausibly empty" means picking a byte or line threshold, and there is no honest number. SanityResults.xcresult runs a single test and its whole run log is legitimately short; a threshold that catches the husk either catches that too or is tuned to this one bundle. The cardinal rule is already written into Fault.Kind.unresolvedLog — "a run carrying no log reference at all is structural absence, not degradation, and is never flagged" — and inventing a plausibility bar is the same move as fabricating a (0.00s).

There is exactly one signal that needs no threshold: the document carried messages and the exported text contains none of them. After this change that is unreachable by construction — one shape, one formatter, and formatted() emits every message it decodes — so as a runtime fault it could only ever be a tautology guarding code that cannot produce it. It belongs where it now is: RunLogTests pins the formatter's output and DifferentialTests pins that the two backends agree. Tests, not a fault.

Verification

• swift test green on both suite legs (XCHR_RESULT_READER=auto and =modern), including the differential.
• swiftformat --lint clean; swiftlint reports no new violations (the file_length one this first introduced is what prompted the split into DifferentialLogTests.swift).
• Both readers re-rendered from one fixture bundle and the exported logs cmped.

Summary by CodeRabbit

• Bug Fixes

  • Improved log rendering so complete logs display consistently across legacy and modern result formats.
  • Preserved messages, section headers, nested subsections, and unknown log types during export.
  • Log decoding failures are now reported correctly without returning incomplete log data.
  • Legacy and modern exports now produce matching formatted log output.

• Documentation

  • Added release notes describing improved log rendering and compatibility updates.