Version issue-creation REST calls in handle_agent_failure

[Copilot]

The failure-reporting path in handle_agent_failure was emitting unversioned Octokit REST calls (e.g. POST /repos/{owner}/{repo}/issues), which now surface deprecation warnings. This change updates the generated calls to use the current API-versioned contract.

• Problem scope

  • Failure-tracking issue creation in actions/setup/js/handle_agent_failure.cjs used github.rest.issues.create(...) without explicit API version headers, leading to deprecated endpoint usage warnings in workflow runs.

• Code changes

  • Introduced a local GITHUB_API_VERSION constant (2022-11-28).
  • Added headers: { "X-GitHub-Api-Version": GITHUB_API_VERSION } to all issue-creation call sites in this module:
    • parent failure issue creation
    • daily-cap rollup issue creation
    • cascade rollup issue creation
    • primary failure-tracking issue creation

• Test updates

  • Extended handle_agent_failure.test.cjs assertions to verify header propagation on representative issues.create call paths (including cascade rollup creation).

const newIssue = await github.rest.issues.create({
  owner,
  repo,
  title: issueTitle,
  body: issueBody,
  labels: ["agentic-workflows"],
  headers: { "X-GitHub-Api-Version": GITHUB_API_VERSION },
});

[Copilot]

Pull request overview

This pull request updates the failure-reporting path in handle_agent_failure to explicitly version GitHub REST API calls when creating issues, eliminating deprecation warnings caused by unversioned Octokit requests.

Changes:

• Added a GITHUB_API_VERSION constant (2022-11-28) to the handler module.
• Plumbed headers: { "X-GitHub-Api-Version": GITHUB_API_VERSION } into all github.rest.issues.create(...) call sites in handle_agent_failure.cjs.
• Extended unit tests to assert that the API version header is included for representative issue-creation paths (including cascade rollup creation).

Show a summary per file

File	Description
actions/setup/js/handle_agent_failure.cjs	Adds an API version constant and includes the version header in all issue creation REST calls in the failure handler.
actions/setup/js/handle_agent_failure.test.cjs	Adds assertions verifying the version header is passed through on issue creation calls (including cascade rollup).

Copilot's findings

Tip

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

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

[github-actions]

🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅

[github-actions]

✅ PR Code Quality Reviewer completed the code quality review.

[github-actions]

✅ Design Decision Gate 🏗️ completed the design decision gate check.

No ADR enforcement needed: PR #38017 does not have the 'implementation' label (has_implementation_label=false) and has 0 new lines of code in business logic directories (well under the 100-line threshold). Neither Condition A nor Condition B is met.

[github-actions]

🧪 Test Quality Sentinel completed test quality analysis.

[github-actions]

Skills-Based Review 🧠

Applied /tdd — requesting changes on test coverage gaps across the four patched call sites.

📋 Key Themes & Highlights

Key Themes

• Incomplete test coverage: 2 of 4 patched issues.create call sites (parent issue creation and daily-cap rollup) have no assertion verifying that the new X-GitHub-Api-Version header is passed. The PR description acknowledges this as "representative" coverage, but full coverage would close the regression surface completely.
• Minor style inconsistency: the two added assertions use different patterns (toHaveBeenCalledWith(expect.objectContaining(...)) vs direct property access on the extracted call object).

Positive Highlights

• ✅ Extracting GITHUB_API_VERSION as a module-level constant is clean — a single future version bump rather than four scattered string updates.
• ✅ The fix is purely additive and scoped tightly; no existing logic was mutated.
• ✅ The cascade rollup header assertion at line 3168 correctly validates the propagated value.

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · 135.7 AIC · ⌖ 13.3 AIC

[github-actions]

[/tdd] This assertion covers one of the four patched call sites, leaving two paths — parent issue creation (findOrCreateParentIssue, impl line ~575) and daily-cap rollup (findOrCreateDailyCapRollupIssue, impl line ~2138) — without header assertions. If either path accidentally drops the X-GitHub-Api-Version header in a future refactor, no test will catch it.

💡 Suggested additions

In the test for the parent issue creation path:

expect(createIssueMock).toHaveBeenCalledWith(
  expect.objectContaining({
    headers: { "X-GitHub-Api-Version": "2022-11-28" },
  })
);

And similarly in the findOrCreateDailyCapRollupIssue test block. The PR description says coverage was added for "representative" paths, but since the fix touches four distinct call sites, all four warrant explicit assertions to fully close the regression surface.

[Copilot]

Addressed in 6c00eee. Added explicit header coverage for the missing parent-issue and daily-cap create paths in actions/setup/js/handle_agent_failure.test.cjs.

[github-actions]

[/tdd] Minor style inconsistency: this assertion uses direct property access (createCall.headers), while the companion assertion at line 428 uses toHaveBeenCalledWith(expect.objectContaining(...)). Both are functionally correct, but aligning on one pattern across all four call-site tests would improve readability and make the intent — verify header presence on every issues.create invocation — more scannable.

💡 Consistent pattern

If the test already has access to the call arguments via createCall, the direct style used here (expect(createCall.headers).toEqual(...)) is actually more readable. Consider applying it to the test at line 428 too, replacing the toHaveBeenCalledWith(expect.objectContaining(...)) form with the same destructured-call pattern for uniformity.

[Copilot]

Addressed in 6c00eee. The header assertions in actions/setup/js/handle_agent_failure.test.cjs now use the same direct-call pattern for readability.

[github-actions]

Non-blocking feedback on two test coverage gaps.

### Findings summary

2 medium gaps — both non-blocking

1. ensureParentIssue create path is untested (handle_agent_failure.cjs:575): Every existing test mocks search.issuesAndPullRequests to return a pre-existing parent issue, so the issues.create branch inside ensureParentIssue is never reached. The header added here has no test coverage at all.

2. findOrCreateDailyCapRollupIssue header not asserted (handle_agent_failure.test.cjs:426): The daily-cap rollup test (line 743) exercises this callsite and checks the issue title, but skips the headers field. A silent regression is possible.

The implementation change itself is correct — all four issues.create callsites are updated consistently. The two informational inline comments above suggest minimal additions to close the test gaps.

🔎 Code quality review by PR Code Quality Reviewer · ⌖ 13.3 AIC

[github-actions]

Missing header assertion for the findOrCreateDailyCapRollupIssue create path: the existing daily-cap test (around line 743) exercises findOrCreateDailyCapRollupIssue and asserts on the issue title, but does not check headers. A regression that removes the version header from that callsite would go undetected.

💡 Suggested addition

In the daily-cap test block (the one that asserts title: "[aw] Daily failure issue cap exceeded"), add:

expect(createIssueMock).toHaveBeenCalledWith(
  expect.objectContaining({
    headers: { "X-GitHub-Api-Version": "2022-11-28" },
  })
);

This mirrors the pattern already used at line 424 for the main issue creation path.

[Copilot]

Addressed in 6c00eee. The daily-cap rollup test now asserts the X-GitHub-Api-Version header on the create call.

[github-actions]

ensureParentIssue create path has zero header test coverage: the header is added here, but no test ever reaches this branch — every existing test mocks search.issuesAndPullRequests to return an existing parent issue, which causes ensureParentIssue to short-circuit before reaching issues.create. The header change at this callsite is functionally unverified.

💡 Suggested fix

Add a test where the search mock returns an empty result for the parent-issue query, forcing ensureParentIssue to hit the create path, and assert:

expect(createIssueMock).toHaveBeenCalledWith(
  expect.objectContaining({
    headers: { "X-GitHub-Api-Version": "2022-11-28" },
  })
);

A minimal setup is a search mock that returns { total_count: 0, items: [] } only when the query contains "[aw] Failed runs".

[Copilot]

Addressed in 6c00eee. Added a test that enables grouped reports, forces the [aw] Failed runs create path, and verifies the version header on that parent issue creation.

[github-actions]

🧪 Test Quality Sentinel Report

⚠️ Test Quality Score: 70/100 — Acceptable

Analyzed 2 modified test(s): 2 design, 0 implementation, 0 guideline violation(s). Header-assertion additions are well-placed against external API contracts; edge-case and uncovered call-site gaps prevent a higher score.

📊 Metrics & Test Classification (2 tests analyzed)

Metric	Value
New/modified tests analyzed	2
✅ Design tests (behavioral contracts)	2 (100%)
⚠️ Implementation tests (low value)	0 (0%)
Tests with error/edge cases	0 (0%)
Duplicate test clusters	0
Test inflation detected	No (1.2:1 ratio)
🚨 Coding-guideline violations	0

Test Classification Details

Test	File	Classification	Issues Detected
creates a new issue when an open issue only has workflow XML metadata without failure metadata	handle_agent_failure.test.cjs:384	✅ Design	Verifies primary issue-creation call includes correct API version header; no error path
creates a rollup issue and labels individual issues when CASCADE_THRESHOLD is met	handle_agent_failure.test.cjs:3142	✅ Design	Verifies cascade rollup creation passes correct API version header; no error path

Language Support

Tests analyzed:

• 🟨 JavaScript (*.test.cjs, *.test.js): 2 tests (vitest)
• 🐹 Go (*_test.go): 0 tests

⚠️ Suggestions — 2 item(s)

⚠️ Coverage gap: 2 of 4 call sites not explicitly covered

Context: The production change adds headers: { "X-GitHub-Api-Version": GITHUB_API_VERSION } to four issues.create() call sites. The test changes cover the primary failure-tracking path and the cascade rollup path. The parent failure issue creation (≈ line 572) and the daily-cap rollup creation (≈ line 2135) have no new header assertion.

Suggested improvement: Add expect.objectContaining({ headers: { "X-GitHub-Api-Version": "2022-11-28" } }) assertions to the tests that exercise the parent-issue and daily-cap-rollup paths, consistent with what was done for the other two paths.

---

⚠️ No error-path coverage for new behavior

Context: Both modified tests only assert the happy path (header is present and correct). There is no test for edge cases where issues.create rejects (e.g., 422 or 403). Given the narrow scope of this change (adding a constant header), this is a low-priority concern.

Verdict

✅ Check passed. 0% of new assertions are implementation tests (threshold: 30%). Both modified tests enforce observable API-versioning contracts against the GitHub REST interface.

📖 Understanding Test Classifications

Design Tests (High Value) verify what the system does:

• Assert on observable outputs, return values, or state changes
• Cover error paths and boundary conditions
• Would catch a behavioral regression if deleted
• Remain valid even after internal refactoring

Implementation Tests (Low Value) verify how the system does it:

• Assert on internal function calls (mocking internals)
• Only test the happy path with typical inputs
• Break during legitimate refactoring even when behavior is correct
• Give false assurance: they pass even when the system is wrong

Goal: Shift toward tests that describe the system's behavioral contract — the promises it makes to its users and collaborators.

References: §27183529259

🧪 Test quality analysis by Test Quality Sentinel · 196.1 AIC · ⌖ 19 AIC · ◷

[github-actions]

✅ Test Quality Sentinel: 70/100. Test quality is acceptable — 0% of new tests are implementation tests (threshold: 30%). Both modified tests enforce observable API-versioning contracts against the GitHub REST interface. See the detailed report in the comment above for improvement suggestions.

[pelikhan]

@copilot run pr-finisher skill

[Copilot]

@copilot run pr-finisher skill

Done in 6c00eee. I ran the PR-finisher pass: addressed the open review feedback with minimal test-only changes, revalidated locally, and the branch is ready for a maintainer to re-trigger CI on the new HEAD.