Bug: trx-evidence-host-tokens-and-malformed-xml

[drmoisan]

• Work Mode: full-bug

Summary

Committed .trx test evidence across the repository carries host identity tokens, and the ad-hoc
redaction agents apply to remove them silently produces XML that is not well-formed, because the
placeholder is written with angle brackets directly into an XML attribute value. Separately, the coverage
step commits raw Cobertura documents at roughly 10.7 MB each. All three problems come from the same gap:
there is no defined convention for what test-run evidence should look like once it is committed.

Environment

• OS/version: Windows 11 Pro 10.0.26200
• Python version: n/a (.NET Framework 4.8.1; vstest.console.exe TRX logger, AltCover/Cobertura output)
• Command/flags used: vstest.console.exe ... /Logger:trx;LogFileName=<name>.trx, and
  scripts/vscode/Invoke-MSTestWithCoverage.ps1 -CoverageOutput <path>.cobertura.xml
• Data source or fixture: committed evidence trees under docs/features/active/*/evidence/

Steps to Reproduce

1. Run any repository test gate that writes a TRX under a feature's evidence/ tree.
2. Inspect the emitted file: runUser carries <machine>\<account>, computerName carries the host
   name, and storage/codeBase carry the absolute checkout path including the account name. Note that
   vstest lowercases the storage path, so a case-sensitive search for the account name misses it.
3. Apply the redaction agents have been applying, substituting a placeholder written as
   <worktree-root> into those attributes.
4. Parse the result with any XML parser. It fails.

Expected Behavior

Committed test evidence should carry no host, account, or absolute-path token, and should remain
well-formed XML so that a reviewer or a gate can parse it and read its counters. Committed coverage
evidence should be small enough that retaining it is not a repository-size decision.

Actual Behavior

Three distinct failures, all observed on epic/quickfiler-bug-family-integration:

1. Host tokens survive. Feature 488's review (policy-audit.2026-08-28T06-44.md, finding PA-1) found
   the absolute path and the runUser domain token in all 19 of its committed TRX files, and noted the
   same tokens are already present in previously merged sibling evidence (features 501, 608, 439).
2. Redaction breaks the XML. A raw < is not legal in an XML attribute value. Substituting
   <worktree-root> into storage/codeBase made all 19 of feature 488's committed TRX files
   unparseable. This was verified against the committed blobs and went undetected through a full
   feature review, because the review re-derived its coverage figures from the Cobertura documents rather
   than from the TRX. Evidence that cannot be parsed cannot be audited mechanically.
3. Raw Cobertura is large. Feature 488 committed coverage-baseline.cobertura.xml and
   coverage-final.cobertura.xml at roughly 10.7 MB each, 21.4 MB for one feature. Deleting them later
   does not reclaim the space, because the blobs are already in history; the decision is only ever
   prospective.

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: the two token forms, as observed before remediation -
  storage="c:\users\<account>\repos\taskmaster\...\quickfiler.test.dll" (note the lowercasing) and
  runUser="<machine>\<account>". Remediation for 488 is recorded under finding PA-1 in
  docs/features/active/itemviewer-breadcrumb-lifecycle-defects-488/policy-audit.2026-08-28T06-44.md.

Impact / Severity

• Blocker
• High
• Medium
• Low

Medium rather than High: the leaked tokens are a developer account and machine name in a private
repository, not a credential. The parseability defect is the more consequential half, because it silently
degrades the audit trail every gate depends on, and it defeats exactly the mechanical verification that
would otherwise catch a fabricated result.

Source

From: docs/features/potential/2026-08-28-trx-evidence-host-tokens-and-malformed-xml.md

[drmoisan]

Corroborating evidence from item #662's feature review during the bugs-638-644-647 parallel run (2026-09-02): the artifact-hygiene/host-identifier-redaction sweep this issue tracks excludes the plan file from its own residual scan, so a plan file can carry unredacted host identifiers the sweep is supposed to catch everywhere else. This is an additional, distinct gap in the same hygiene mechanism, not a duplicate of the already-recorded XML-malformation finding.

Also confirmed still unresolved in this run: large Cobertura evidence files continued to be committed after this issue was filed (a new ~10MB+ file landed with item #670's delivery), consistent with this issue's "partial" disposition — the large-file problem remains unaddressed. Full detail on the accumulation scale (200+ tracked files) is filed separately as #727.

[drmoisan]

Maintainer decision recorded 2026-09-11: committed test-evidence convention

Applies to this issue, to #727 sub-finding 6, and to the tooling half of #602.

1. Raw Cobertura documents are no longer committed. Feature evidence commits a projection only: the package-level JaCoCo XML already used by item Bug: qfc-metrics-flush-writes-empty-session-file #646 (PR fix(quickfiler): skip the metrics write when no diagnostic lines survive (#646) #718) and the one-line first-party summary emitted by Get-CoberturaFirstPartyCoverageReport.
2. Raw .trx files are no longer committed. Feature evidence commits a summary only (passed, failed, skipped, total, and the names of any failed tests). Because no TRX is committed, no XML redaction step exists and the malformed-XML failure mode described here cannot recur.
3. Raw output is discarded after the projection is written. It is not retained under a gitignored path.
4. Test-invocation scripts set an explicit /ResultsDirectory: and LogFileName= so the default <account>_<HOST>_<timestamp>.trx name is never produced, even transiently.

Measured on main at the time of the decision: 332 tracked .trx files (281 MB) and 248 tracked .cobertura.xml files (3,227 MB in the working tree, largest 42.6 MB). The convention is prospective; it does not rewrite history. The existing tracked files are handled by the historical sweep item under #602.

This issue is scheduled into the consolidated bug parallel run being planned on 2026-09-11.