[CI Failure Doctor] Live GitHub API frontmatter hash test times out in run #34696

[github-actions]

🏥 CI Failure Investigation - Run #34696

Summary

js-integration-live-api now consistently fails because the live GitHub API integration test (frontmatter_hash_github_api.test.cjs) cannot finish within the 10-second Vitest timeout. Running GITHUB_TOKEN=ghp_xxx npm test -- frontmatter_hash_github_api.test.cjs reproduces the timeout once the test hits the should compute hash using real GitHub API (no mocks) block.

Failure Details

• Run: 21871369067
• Commit: 01056b879fce5810d5a3c0d712121442da497c25
• Trigger: push

Root Cause Analysis

computeFrontmatterHash fetches .github/workflows/audit-workflows.md and all imported workflows via createRetryableFileReader, issuing many sequential octokit.repos.getContent calls over the GitHub API. Fetching the entire import tree is now too slow for the built-in 10 s Vitest timeout, so the live integration test always gets aborted at line 336 before the hash completes.

Failed Jobs and Errors

• js-integration-live-api: vitest run --no-file-parallelism frontmatter_hash_github_api.test.cjs

```
Error: Test timed out in 10000ms.
 ❯ frontmatter_hash_github_api.test.cjs:336:7
```

Investigation Findings

• The failure occurs inside the live GitHub API integration it block (line 336). The test spent ~10.23 seconds running before Vitest killed it, so it never reaches the hash verification.
• The test exercise hits multiple exported workflows with nested imports. Each imported file triggers its own GitHub API request, so latency accumulates and now exceeds 10 seconds even without transient failures.
• The retry wrapper (createRetryableFileReader) still makes the same sequential calls, so the test cannot progress in the allotted time even though the API eventually responds.

Recommended Actions

• Increase the Vitest/GitHub API test timeout (e.g., pass 30000 as the third argument to it or set a higher testTimeout) for the live integration test so the hash computation can finish when multiple API calls are required.
• Consider pointing the live test at a smaller fixture or caching the imports locally instead of traversing the entire audit-workflows.md tree, reducing the number of GitHub API calls in CI.

Prevention Strategies

Move network-heavy live API tests into a separate job with relaxed deadlines or gate them behind an opt-in flag (e.g., RUN_LIVE_API_TESTS=true) so transient network latency cannot break the default CI runs.

AI Team Self-Improvement

When adding tests that talk to the GitHub API, always treat them as slow and set explicit timeouts/retries, or make them opt-in so CI doesn’t fail on spikes in API latency.

Historical Context

Issue #14387 (Run #34273) already called out fragility in the frontmatter_hash live API test surface—back then the JavaScript hash had to be aligned with the Go implementation, and rerunning the live test was flaky after the runtime dedup change. The same area continues to produce timing-sensitive failures.

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 11, 2026, 3:46 PM UTC

[github-actions]

This issue is being closed as outdated. A newer issue has been created: #14811

View newer issue

---

This action was performed automatically by the CI Failure Doctor workflow.