[aw-fixer] Traverse aggregate Helix submissions independently

[vitek-karas]

#1731

Summary

• Treat failed Monitor Helix Jobs tasks as aggregate signals rather than requiring a one-to-one timeline relationship with one submission.
• Enumerate every successful Helix submission in the selected build, deduplicate by log ID, and inspect each independently.
• Regenerate the workflow lock file with gh-aw v0.86.2.

Incident

• Workflow run: https://github.com/dotnet/xharness/actions/runs/35041888104
• Failed job: https://github.com/dotnet/xharness/actions/runs/35041888104/job/104623563530

The required timelines expose only aggregate failed Helix-monitor tasks, while dozens of independent successful submission tasks have no timeline association to those failures.

The observer stopped with missing_data because it tried to correlate an aggregate monitor failure to a specific successful submission. The timeline instead contains multiple independent successful submission tasks. Each submission log can identify its own downstream Helix job, so no monitor-to-submission relationship is required.

Fix

The workflow now explicitly treats the monitor task as an aggregate signal and traverses all successful submission tasks independently. Missing timeline association no longer makes the scan incomplete; actual request and payload failures retain the existing strict handling.

Validation

• gh aw compile .github/workflows/runtime-failure-observer.agent.md
• Compiler result: 1 workflow succeeded with 0 warnings using the lock file's recorded v0.86.2 compiler.
• git diff --check

Deduplication

No open PR matched the occurrence key, fingerprint, run URL, issue URL, changed files, or failure signature. The earlier Helix evidence change in #1729 was already present at the failing run's head. The only PR merged after this occurrence, #1728, changed GitHub deduplication rather than Helix submission traversal.

aw-fixer fingerprint

{
  "aw_fixer": {
    "schema": 1,
    "kind": "fix-pr",
    "occurrence_keys": ["run:35041888104", "issue:5468980798"],
    "incident_fingerprint": "7eb64f1dd6fe0151ea72",
    "source_runs": ["https://github.com/dotnet/xharness/actions/runs/35041888104"],
    "source_issues": ["https://github.com/dotnet/xharness/issues/1731"]
  }
}

[vitek-karas]

Analysis

The failed job ended at Fail incomplete observer scan after the agent emitted missing_data.

Evidence:

• Run: https://github.com/dotnet/xharness/actions/runs/35041888104
• Job: https://github.com/dotnet/xharness/actions/runs/35041888104/job/104623563530
• Generated issue: [aw] Runtime Failure Observer (xharness) is missing required data #1731
• Failing run head: 225f4dfefc66973c1f37623cd65d0470d389a63d

The relevant output says the timeline had failed aggregate Monitor Helix Jobs tasks plus 34 and 23 independent successful submission tasks, but no timeline relationship that selected one submission. The workflow text in .github/workflows/runtime-failure-observer.agent.md required reconstructing the timeline hierarchy and referred to a selected submission task, so the agent stopped rather than traversing the independent submissions.

The fix changes the Step 2 guidance to:

• treat Monitor Helix Jobs as an aggregate signal;
• enumerate all successful submission tasks in the selected build;
• deduplicate submission tasks by log.id;
• inspect each submission independently; and
• avoid classifying absent monitor-to-submission relationships as missing_data.

Existing-work searches found no open PR or PR merged after the occurrence with this run, issue, fingerprint, or failure signature. #1729 was already included in the failing run head and handles unavailable retained evidence after a submission is selected; it does not define traversal when aggregate monitors have no one-to-one submission relationship. #1728 merged after the occurrence but changes GitHub deduplication only.

Rejected alternatives:

• Requiring inferred timeline relationships would preserve the observed failure.
• Selecting one of the successful submissions would be speculative and could miss the actual failing work item.
• Weakening request or malformed-payload handling is unnecessary; those cases retain the existing strict failure behavior.

aw-fixer fingerprint

{
  "aw_fixer": {
    "schema": 1,
    "kind": "analysis",
    "occurrence_keys": ["run:35041888104", "issue:5468980798"],
    "incident_fingerprint": "7eb64f1dd6fe0151ea72",
    "source_runs": ["https://github.com/dotnet/xharness/actions/runs/35041888104"],
    "source_issues": ["https://github.com/dotnet/xharness/issues/1731"]
  }
}

[vitek-karas]

Next action

Review the Step 2 wording for these invariants:

• aggregate monitor failures trigger traversal of all successful Helix submissions in the selected build;
• submission logs are fetched once per distinct log.id;
• each submission remains subject to the existing evidence-retention skip rules; and
• request failures and malformed payloads still stop the scan.

The workflow compiles with gh-aw v0.86.2 with 0 warnings. Remaining validation is the next scheduled or manual observer run against a build containing multiple independent Helix submissions.

aw-fixer fingerprint

{
  "aw_fixer": {
    "schema": 1,
    "kind": "next-action",
    "occurrence_keys": ["run:35041888104", "issue:5468980798"],
    "incident_fingerprint": "7eb64f1dd6fe0151ea72",
    "source_runs": ["https://github.com/dotnet/xharness/actions/runs/35041888104"],
    "source_issues": ["https://github.com/dotnet/xharness/issues/1731"]
  }
}