Fix handle_noop_message tests failing due to unmocked loadAgentOutput

[Copilot]

Tests used vi.mock() at module level but imported handle_noop_message.cjs with cache-busting timestamps (?t= + Date.now()), bypassing the mock. Real loadAgentOutput executed without GH_AW_AGENT_OUTPUT set, returning early and failing assertions.

Changes

• Replace vi.mock() with temporary file creation in tests
• Set GH_AW_AGENT_OUTPUT to temp files containing actual JSON data
• Clean up temp directories in afterEach()

Before/After

Before:

vi.mock("./load_agent_output.cjs", () => ({
  loadAgentOutput: vi.fn(),
}));

mockLoadAgentOutput.mockReturnValue({
  success: true,
  items: [{ type: "noop", message: "Done" }],
});

After:

const tempDir = fs.mkdtempSync(path.join(os.tmpdir(), "handle-noop-test-"));
const outputFile = path.join(tempDir, "agent_output.json");
fs.writeFileSync(outputFile, JSON.stringify({
  items: [{ type: "noop", message: "Done" }],
}));
process.env.GH_AW_AGENT_OUTPUT = outputFile;

This matches the pattern in load_agent_output.test.cjs and tests the full file I/O flow.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[CI Failure Doctor] CI Failure Investigation - Run #21812475080</issue_title>
<issue_description># 🏥 CI Failure Investigation - Run github/gh-aw#21812475080

Summary

The js job fails immediately after the new actions/setup/js/handle_noop_message.cjs script was introduced because the Vitest suite is now hitting the real loadAgentOutput helper without any GH_AW_AGENT_OUTPUT env var or stubbed data, so it short-circuits before posting the expected no-op comment.

Failure Details

• Run: 21812475080
• Commit: 84109fa0e5fa2a6c2d4dff00b276ab80e2f345b7
• Trigger: push

Root Cause Analysis

handle_noop_message.cjs now requires load_agent_output.cjs inside main and immediately reads GH_AW_AGENT_OUTPUT to assert that only noop outputs were produced. In the test run, the environment variable is unset and the mock is never exercised, so the real helper logs "No GH_AW_AGENT_OUTPUT environment variable found" and returns { success: false }, which makes the rest of the test path (asserting core.info calls and GitHub REST calls) unreachable.

Failed Jobs and Errors

• js – cd actions/setup/js && npm test
  • actions/setup/js/handle_noop_message.test.cjs threw multiple AssertionErrors and TypeErrors (see lines 109, 154, 214, 247, 274, 298, 323) because the expected core.info messages/GitHub calls against the agent runs issue never ran.
  • Key log excerpt: No GH_AW_AGENT_OUTPUT environment variable found followed by No agent output found, skipping, proving the real loader ran and aborted before the assertions.

Investigation Findings

1. The new script performs environment-dependent loading before any mocks or stubs are exercised, so Vitest now hits the real loader when GH_AW_AGENT_OUTPUT is absent.
2. Every failing assertion in handle_noop_message.test.cjs is downstream of that early return, which is why we also see empty vi.fn() call counts and TypeError: Cannot read properties of undefined (reading '0') at the GitHub comment assertions.
3. Running cd actions/setup/js && npm test -- handle_noop_message.test.cjs without setting GH_AW_AGENT_OUTPUT reproduces the failure locally (the loader logs the same missing environment message and exits early).

Recommended Actions

• Update the test setup so that GH_AW_AGENT_OUTPUT points to a temporary file (or the loader is mocked) before importing handle_noop_message.cjs, ensuring loadAgentOutput returns a noop-only items array.
• If direct mocking is preferred, allow handle_noop_message to accept an injectable output loader or test-specific override so the real file reader is never executed in unit tests.

Prevention Strategies

Document and enforce that any new JS workflow helpers that read GH_AW_AGENT_OUTPUT must have a deterministic way to supply that file during tests (either via fixture files or injected mocks) before requiring the module.

AI Team Self-Improvement

When adding JS helpers that consume GH_AW_AGENT_OUTPUT, always stub loadAgentOutput or supply a known JSON file before importing the helper; otherwise, Vitest will fall through to the real loader and fail with "No GH_AW_AGENT_OUTPUT environment variable found" and a cascade of assertion exceptions.

Historical Context

We checked the existing [CI Failure Doctor] issues with the cookie label and they are all closed (#14550, #14392, etc.). None mention handle_noop_message or this new JS path, so this is a fresh investigation.

AI generated by CI Failure Doctor

To add this workflow in your repository, run gh aw add githubnext/agentics/workflows/ci-doctor.md@ea350161ad5dcc9624cf510f134c6a9e39a6f94d. See usage guide.

• expires on Feb 10, 2026, 4:45 AM UTC

Comments on the Issue (you are @copilot in this section)

• Fixes [CI Failure Doctor] CI Failure Investigation - Run #21812475080 #14586

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

Updates the handle_noop_message Vitest suite to avoid vi.mock() being bypassed by cache-busted dynamic imports, by supplying real agent-output JSON via GH_AW_AGENT_OUTPUT temp files (matching the repo’s established pattern for env-based file loaders).

Changes:

• Removes the module-level vi.mock("./load_agent_output.cjs") approach in favor of writing real JSON fixtures to temp files.
• Sets process.env.GH_AW_AGENT_OUTPUT to those temp files per test case to exercise the actual file I/O path.
• Cleans up temporary directories in afterEach().

---

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

[Copilot]

The same agent-output fixture setup (compute outputFile path, write JSON, set GH_AW_AGENT_OUTPUT) is duplicated across many test cases in this file. Consider extracting a small helper (e.g., writeAgentOutput(items) returning the file path and setting the env var) to reduce repetition and make future test additions less error-prone.