fix: filter AWF infrastructure lines from engine failure context

[Copilot]

During the Apr 8 systemic outage, 13+ workflows failed with exit code 1 before producing any agent output. The buildEngineFailureContext fallback was showing AWF container lifecycle messages as "Last agent output" in failure issues — confusing and useless for diagnosis:

Container awf-squid  Removed
[SUCCESS] Containers stopped successfully
[WARN] Command completed with exit code: 1
Process exiting with code: 1

Changes

• Infrastructure line filter: Uses the shared AWF_INFRA_LINE_RE constant (extracted into log_parser_shared.cjs) in buildEngineFailureContext. Infrastructure lines are stripped before the fallback tail is selected, so only actual engine output appears.

• Shared constant: AWF_INFRA_LINE_RE is now defined once in log_parser_shared.cjs and imported by both parse_copilot_log.cjs and handle_agent_failure.cjs, eliminating duplication and preventing future drift.

• Startup-failure detection: When the log contains only infrastructure lines — the engine exited before producing anything — a dedicated message is shown instead of the generic "terminated unexpectedly" + useless tail. The message is engine-aware: copilot engine failures reference the GitHub Copilot status page; all other engines (claude, codex, custom) reference a generic provider status page:

  ⚠️ Engine Failure: The copilot engine terminated before producing output.
  The engine exited immediately without producing any output. This often indicates a transient infrastructure issue (e.g., service unavailable, API rate limiting). If this failure recurs, check the GitHub Copilot status page and review the firewall audit logs.

• No change to issue creation logic: Failure issues are still created in all cases; only the diagnostic context surfaced in those issues is improved.

• 5 new tests covering: infra-only log → startup-failure message; mixed log → infra lines excluded from tail; [entrypoint]/[health-check] prefix handling; engine ID label in startup-failure message; provider-agnostic status page guidance for non-copilot engines.

[Copilot]

Pull request overview

Improves diagnostic output for workflow engine failures by removing AWF (container/firewall wrapper) infrastructure noise from the buildEngineFailureContext fallback and emitting a dedicated “startup failure” message when the engine produces no real output.

Changes:

• Filter AWF infrastructure lines from agent-stdio.log before selecting the fallback “tail” context.
• Add a dedicated startup-failure message when logs contain only infrastructure lines.
• Add new tests covering infra-only logs, mixed logs, [entrypoint]/[health-check] prefixes, and engine ID inclusion; add a patch changeset.

Show a summary per file

File	Description
actions/setup/js/handle_agent_failure.cjs	Filters infra lines from fallback tail and adds startup-failure messaging when no engine output exists.
actions/setup/js/handle_agent_failure.test.cjs	Adds test cases validating infra filtering and the new startup-failure behavior.
.changeset/patch-fix-infra-lines-in-engine-failure-context.md	Documents the patch-level change for release notes/versioning.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 3/3 changed files
• Comments generated: 2

[Copilot]

The startup-failure message always tells users to check the “GitHub Copilot status page”, but this code path is used for any engine ID (e.g. tests already cover claude). For non-copilot engines this guidance is inaccurate/misleading. Consider making the wording engine-agnostic or conditionally mentioning the Copilot status page only when GH_AW_ENGINE_ID === "copilot" (and using a generic provider/status message otherwise).

Suggested change

	// (e.g., Copilot API service unavailable, rate-limiting, token not yet provisioned).
	core.info("agent-stdio.log contains only infrastructure lines — engine likely failed at startup (possible transient failure)");
	let context = `\n**⚠️ Engine Failure**: The${engineLabel} engine terminated before producing output.\n\n`;
	context +=
	"The engine exited immediately without producing any output. This often indicates a transient infrastructure issue (e.g., service unavailable, API rate limiting). " +
	"If this failure recurs, check the GitHub Copilot status page and review the firewall audit logs.\n\n";
	// (e.g., API service unavailable, rate-limiting, token not yet provisioned).
	core.info("agent-stdio.log contains only infrastructure lines — engine likely failed at startup (possible transient failure)");
	const recurringFailureGuidance =
	process.env.GH_AW_ENGINE_ID === "copilot"
	? "If this failure recurs, check the GitHub Copilot status page and review the firewall audit logs.\n\n"
	: "If this failure recurs, check the provider status page (if available) and review the firewall audit logs.\n\n";
	let context = `\n**⚠️ Engine Failure**: The${engineLabel} engine terminated before producing output.\n\n`;
	context +=
	"The engine exited immediately without producing any output. This often indicates a transient infrastructure issue (e.g., service unavailable, API rate limiting). " +
	recurringFailureGuidance;

[Copilot]

INFRA_LINE_RE is duplicated here and in actions/setup/js/parse_copilot_log.cjs:156. Since the comment explicitly says this must stay in sync, consider extracting it into a shared constant/module (e.g. alongside other log parsing helpers) to prevent future drift when the infrastructure log format changes.

[pelikhan]

@copilot review comments

[Copilot]

@copilot review comments

Both review comments addressed in f40da83:

1. Engine-specific status page guidance — buildEngineFailureContext now shows "GitHub Copilot status page" only when GH_AW_ENGINE_ID === "copilot", and "provider status page (if available)" for all other engines (claude, codex, custom, etc.). New test shows provider-agnostic status page guidance for non-copilot engines covers this.

2. INFRA_LINE_RE duplication — Extracted as AWF_INFRA_LINE_RE into log_parser_shared.cjs with full documentation. Both parse_copilot_log.cjs and handle_agent_failure.cjs now import it from the shared module — no more drift risk.