@axe-core/cli: Chrome tab crashes after ~4 minutes during accessibility scan in GitHub Actions

[turbolego]

Describe the bug

@axe-core/cli experiences a WebDriver tab crash after approximately 4 minutes of scanning, causing the entire test suite to fail in GitHub Actions CI/CD environment. The crash occurs consistently during automated accessibility testing of auto-generated web content, even though the same content passes W3C HTML validation without issues. The crash appears to be related to resource constraints or timeouts in the headless Chrome environment.

To Reproduce

Steps to reproduce the behavior:

1. Set up a GitHub Actions workflow on ubuntu-latest (Ubuntu 24.04)
2. Install Node.js v24 and global dependencies:

   npm ci
   npm install -g pa11y @qualweb/cli "chromedriver@^147" @axe-core/cli

3. Start a local HTTP server: http://localhost:28763
4. Run W3C HTML validation on test content (this completes successfully)
5. Run @axe-core/cli to scan the same page via axe http://localhost:28763/path/to/test.html --headless --chromedriver-version 147
6. Observe: Chrome tab crashes after ~240 seconds with WebDriverError: tab crashed

Expected behavior

@axe-core/cli should complete the accessibility scan and generate a JSON report without crashing the browser tab.

Actual behavior

Chrome tab crashes with a WebDriverError after ~4 minutes, halting the scan and preventing accessibility violations from being reported. The stack trace shows the crash originates from Selenium WebDriver's HTTP communication layer with no clear indication of the root cause.

Error Output:

Error: WebDriverError: tab crashed
  (Session info: chrome=147.0.7727.55)
    at Object.throwDecodedError (/opt/hostedtoolcache/node/24.14.1/x64/lib/node_modules/@axe-core/cli/node_modules/selenium-webdriver/lib/error.js:523:15)
    at parseHttpResponse (/opt/hostedtoolcache/node/24.14.1/x64/lib/node_modules/@axe-core/cli/node_modules/selenium-webdriver/lib/http.js:526:13)
    at Executor.execute (/opt/hostedtoolcache/node/24.14.1/x64/lib/node_modules/@axe-core/cli/node_modules/selenium-webdriver/lib/webdriver.js:458:28)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async Driver.execute (/opt/hostedtoolcache/node/24.14.1/x64/lib/node_modules/@axe-core/cli/node_modules/selenium-webdriver/lib/webdriver.js:745:17) {
  remoteStacktrace: ''
}
Error: axe failed

Execution Timeline:

• T+0s: axe-core scan starts
• T+30s: W3C HTML validation completes successfully
• T+240s: Chrome tab crashes during axe scan
• Test suite fails immediately

Environment

• OS: Ubuntu 24.04 LTS (GitHub Actions runner: ubuntu-latest)
• Chrome: 147.0.7727.55
• ChromeDriver: 147.0.7727.57 (version-matched)
• Node.js: v24.14.1
• @axe-core/cli: Latest version
• Selenium WebDriver: Latest (bundled with @axe-core/cli)
• Test Environment: Containerized GitHub Actions runner with standard resource allocations

Additional context

• Reproducibility: 100% reproducible in this workflow; crashes consistently on first iteration
• Pre-crash status: The test page passes W3C HTML validation before axe crashes, indicating valid HTML
• Content source: Test content is auto-generated by an LLM, complexity varies between runs
• Configuration: No custom browser arguments or special axe-core configuration being used
• HTTP server: Running locally within the same runner (localhost:28763)

Questions for Investigation:

1. Are there known memory constraints or resource exhaustion conditions in GitHub Actions runners that could cause tab crashes during long-running scans?
2. Does @axe-core/cli have built-in timeout protections or memory-based safeguards that might be terminating scans prematurely?
3. Are there recommended CLI flags or browser arguments for running axe-core in resource-constrained CI/CD headless environments?
4. Could this be a Selenium WebDriver compatibility issue with Chrome v147 in headless mode?

Suggested improvements:

• Add explicit timeout handling with informative error messages distinguishing between timeout and resource exhaustion
• Implement memory monitoring during scans with early termination and clear diagnostics
• Add automatic retry logic for transient tab crashed errors
• Provide better debugging output indicating potential resource constraints before crashes occur