@htekdev/actions-debugger 1.0.119 → 1.0.121

package/errors/caching-artifacts/caching-artifacts-071.yml

@@ -0,0 +1,114 @@
+id: caching-artifacts-071
+title: 'actions/cache Fails on Self-Hosted Runner with IPv6 Cache Server URL'
+category: caching-artifacts
+severity: error
+tags:
+  - cache
+  - ipv6
+  - self-hosted
+  - getaddrinfo
+  - ENOTFOUND
+  - internal-cache
+patterns:
+  - regex: 'getaddrinfo ENOTFOUND \[[\da-fA-F:]+\]'
+    flags: 'i'
+  - regex: 'getCacheEntry failed.*getaddrinfo ENOTFOUND'
+    flags: 'i'
+  - regex: 'reserveCache failed.*getaddrinfo ENOTFOUND.*\['
+    flags: 'i'
+error_messages:
+  - "::warning::Failed to restore: getCacheEntry failed: getaddrinfo ENOTFOUND [2001:bc8:1d90:1fc1:dc00:ff:fe2b:3f97]"
+  - "::warning::Failed to save: reserveCache failed: getaddrinfo ENOTFOUND [2001:db8::1]"
+root_cause: |
+  When GitHub Actions self-hosted runner infrastructure uses an IPv6 address for
+  the internal cache service URL (ACTIONS_CACHE_URL), the @actions/http-client
+  in the toolkit fails to connect because it treats the bracketed IPv6 literal
+  as a hostname string instead of an address.
+
+  DNS resolution of `[2001:bc8:...]` fails with ENOTFOUND because the brackets
+  are IANA-standard URL notation for IPv6 literals in HTTP URLs
+  (RFC 2732 / RFC 3986 section 3.2.2), but the toolkit's Node.js http-client
+  was passing the bracketed string directly to `getaddrinfo()` without stripping
+  the brackets first. getaddrinfo does not accept bracket-wrapped IPv6 literals
+  and returns ENOTFOUND.
+
+  This affects any self-hosted runner environment where:
+  - The cache service is configured with an IPv6 address directly in the URL
+    (e.g., ACTIONS_CACHE_URL=http://[2001:bc8::1]:3000/)
+  - This includes ARC (Actions Runner Controller) on IPv6-only Kubernetes clusters,
+    enterprise GitHub Actions server deployments, and any on-prem cache proxy
+    bound to an IPv6 interface
+
+  The fix (strip brackets before passing to http-client) was submitted as PR
+  actions/toolkit#2298. Until merged and released in a new version of actions/cache,
+  the bug is present in actions/cache@v3, v4, and v5.
+fix: |
+  Short-term workarounds (choose one):
+
+  1. Configure the internal cache service to also listen on an IPv4 address or
+     hostname and set ACTIONS_CACHE_URL to use the IPv4 address or hostname:
+       export ACTIONS_CACHE_URL=http://cache.internal:3000/
+       export ACTIONS_CACHE_URL=http://192.168.1.10:3000/
+
+  2. Set ACTIONS_CACHE_URL to use the hostname that resolves to the IPv6 address
+     (DNS-based resolution of the hostname works; the issue is only with bare
+     IPv6 literals in brackets):
+       export ACTIONS_CACHE_URL=http://cache-server.local:3000/
+
+  3. Add the cache service IPv6 address to /etc/hosts with a hostname alias on
+     the runner and use that hostname in ACTIONS_CACHE_URL.
+
+  Long-term: Track actions/toolkit#2298 for the upstream fix. Once merged and
+  actions/cache releases a new version using the patched toolkit, upgrade to
+  that version.
+fix_code:
+  - language: yaml
+    label: 'Broken — ACTIONS_CACHE_URL with IPv6 literal causes ENOTFOUND'
+    code: |
+      # Runner environment configuration (runsvc.sh or .env file):
+      # ACTIONS_CACHE_URL=http://[2001:bc8:1d90:1fc1:dc00:ff:fe2b:3f97]:3000/
+      #
+      # Workflow sees:
+      # ::warning::Failed to restore: getCacheEntry failed: getaddrinfo ENOTFOUND [2001:bc8:...]
+
+      - uses: actions/cache@v5
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
+      # Warning: cache restore/save fails silently with ENOTFOUND
+
+  - language: yaml
+    label: 'Fixed — set ACTIONS_CACHE_URL to hostname or IPv4 instead of IPv6 literal'
+    code: |
+      # Runner environment configuration — use hostname instead of IPv6 literal:
+      # ACTIONS_CACHE_URL=http://cache.internal:3000/
+      # -or-
+      # ACTIONS_CACHE_URL=http://192.168.1.10:3000/
+      #
+      # The cache action now resolves the hostname normally:
+      - uses: actions/cache@v5
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
+
+  - language: yaml
+    label: 'Diagnostic — detect IPv6 ENOTFOUND cache failures in workflow output'
+    code: |
+      - name: Check cache URL for IPv6 literal
+        run: |
+          if [[ "${ACTIONS_CACHE_URL:-}" =~ ^\[.*\] ]] || [[ "${ACTIONS_CACHE_URL:-}" == *"["* ]]; then
+            echo "::warning::ACTIONS_CACHE_URL contains an IPv6 literal: ${ACTIONS_CACHE_URL}"
+            echo "::warning::Cache actions will fail with ENOTFOUND. Use a hostname or IPv4 address instead."
+          fi
+
+prevention:
+  - 'Always configure ACTIONS_CACHE_URL with a hostname or IPv4 address, not a bare IPv6 literal in brackets.'
+  - 'When deploying ARC or enterprise runner infrastructure on IPv6-only Kubernetes nodes, set up a hostname alias for the cache service.'
+  - 'Test cache operations with a simple cache-hit workflow on a new self-hosted runner before deploying to production.'
+docs:
+  - url: 'https://github.com/actions/cache/issues/1718'
+    label: 'actions/cache#1718 — Caching fails on IPv6 cache server'
+  - url: 'https://github.com/actions/toolkit/pull/2298'
+    label: 'actions/toolkit#2298 — Fix: correctly handle IPv6 literals in http-client'
+  - url: 'https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2'
+    label: 'RFC 3986 §3.2.2 — IPv6 literals in URL host component (bracket notation)'

package/errors/concurrency-timing/concurrency-timing-058.yml

@@ -0,0 +1,121 @@
+id: concurrency-timing-058
+title: "concurrency queue:max 100-Slot Overflow Silently Cancels the Oldest Pending Run"
+category: concurrency-timing
+severity: silent-failure
+tags:
+  - concurrency
+  - queue-max
+  - silent-cancel
+  - pending
+  - overflow
+  - deployment
+patterns:
+  - regex: 'queue.*max|queue:.*max'
+    flags: 'i'
+  - regex: 'This run was cancelled|run.*cancelled'
+    flags: 'i'
+error_messages:
+  - "This run was cancelled."
+  - "Run was cancelled."
+root_cause: |
+  GitHub Actions concurrency queue:max allows up to 100 workflow runs or jobs
+  to wait in a single concurrency group instead of being cancelled immediately.
+  When the 100-slot queue is already full and a new run arrives, the oldest
+  pending run in the queue is silently cancelled to make room.
+
+  The cancelled run shows "This run was cancelled." in the UI with no
+  indication that the cancellation was caused by queue overflow. This message
+  is identical to normal concurrency cancel-in-progress cancellations, making
+  it impossible to distinguish overflow cancellation from intentional
+  cancellation without additional observability.
+
+  This problem surfaces when:
+  - A pipeline is slower than the push rate (runs queue faster than they drain)
+  - A burst of commits or tags fires many workflow runs simultaneously
+  - A monorepo path filter causes many unrelated commits to all queue in the
+    same deployment concurrency group
+  - A workflow is accidentally triggered on every push to any branch and all
+    share a single production-deploy concurrency group
+
+  Note: queue:max and cancel-in-progress:true cannot be combined (validation
+  error). queue:max assumes you want all runs to eventually execute in order.
+fix: |
+  queue:max with 100 slots is generous for most pipelines. If you are hitting
+  the overflow limit, the queue depth is a symptom of a throughput mismatch:
+
+  1. Speed up the job so the queue drains faster than it fills. Profile and
+     optimize the slowest steps (build caching, parallelism inside the job).
+
+  2. Narrow the trigger to reduce unnecessary queuing:
+     - Use paths: filters so only relevant changes trigger the workflow
+     - Only trigger on specific branches (main, release/*) not all branches
+     - Use workflow_dispatch for on-demand deploys instead of automatic pushes
+
+  3. Split into multiple concurrency groups scoped per environment or service
+     component. Each group has its own 100-slot limit, distributing capacity
+     across workloads.
+
+  4. If strict ordering is not required and drops are acceptable, switch back
+     to queue:single (the default) with cancel-in-progress:false so only one
+     pending run is kept, avoiding the 100-slot limit entirely.
+fix_code:
+  - language: yaml
+    label: "queue:max — silently cancels oldest pending run when >100 queued"
+    code: |
+      on:
+        push:
+          branches: ['**']  # Triggers on every push to every branch
+
+      concurrency:
+        group: production-deploy     # All branches share ONE slot — queue fills fast
+        queue: max                   # Up to 100 queued; 101st silently cancels the 1st
+
+  - language: yaml
+    label: "Fixed — scope concurrency group per environment + narrow push trigger"
+    code: |
+      on:
+        push:
+          branches:
+            - main
+            - 'release/**'
+
+      concurrency:
+        # Each environment gets its own 100-slot queue
+        group: deploy-${{ github.event.deployment.environment || 'staging' }}-${{ github.ref_name }}
+        queue: max
+
+  - language: yaml
+    label: "Fixed — add observability step to detect queue overflow"
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          concurrency:
+            group: production-deploy
+            queue: max
+          steps:
+            - name: Check concurrency queue depth
+              env:
+                GH_TOKEN: ${{ github.token }}
+              run: |
+                PENDING=$(gh api \
+                  "repos/${{ github.repository }}/actions/runs?status=waiting&per_page=100" \
+                  --jq '[.workflow_runs[] | select(.name == "${{ github.workflow }}")] | length')
+                echo "Runs currently waiting in concurrency queue: $PENDING"
+                if [ "${PENDING:-0}" -ge 90 ]; then
+                  echo "::warning::Queue near capacity (${PENDING}/100). Oldest run may be dropped on next push."
+                fi
+
+            - name: Deploy
+              run: ./deploy.sh
+prevention:
+  - "Monitor pipeline throughput: if runs consistently back up to 50+ in queue, the job is too slow for the push frequency."
+  - "Narrow workflow triggers with paths: and branches: filters to reduce unnecessary queuing."
+  - "Scope concurrency groups per environment or service to distribute the 100-slot limit across workloads."
+  - "Use queue:max only when strict ordering matters (deployments). For CI checks, cancel-in-progress:true is preferable."
+  - "The combination queue:max and cancel-in-progress:true is a workflow validation error — do not use both."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-concurrency"
+    label: "GitHub Docs — Using concurrency (queue:max behavior and 100-slot limit)"
+  - url: "https://docs.github.com/en/actions/reference/limits"
+    label: "GitHub Actions Limits — Concurrency group queue: 100 runs per group"

package/errors/known-unsolved/known-unsolved-069.yml

@@ -0,0 +1,127 @@
+id: known-unsolved-069
+title: "Matrix Strategy Hard Limit: 256 Jobs Per Workflow Run"
+category: known-unsolved
+severity: error
+tags:
+  - matrix
+  - strategy
+  - job-limit
+  - dynamic-matrix
+  - fromjson
+  - scalability
+patterns:
+  - regex: 'matrix.*generates.*too many|too many.*entries.*matrix'
+    flags: 'i'
+  - regex: 'limited to 256|exceeding.*allowed maximum.*256|256.*jobs.*per.*workflow'
+    flags: 'i'
+error_messages:
+  - "Matrix generates too many entries. Limited to 256."
+root_cause: |
+  GitHub Actions enforces a hard limit of 256 jobs per workflow run across
+  all matrix dimensions. This is calculated as the total Cartesian product of
+  all matrix axes after applying include/exclude entries.
+
+  Common triggers:
+  - Dynamic matrices from fromJSON output that grow over time as new targets
+    are added to a test matrix config file
+  - Multi-dimensional matrices (os x language x version) where the product
+    of all axis sizes exceeds 256
+  - Adding include: entries on top of an already-large base matrix, each
+    include: adds one additional job that counts against the 256 limit
+  - Monorepo CI matrices that test all services x all supported runtimes
+
+  The error fires immediately when the workflow is queued and prevents any
+  jobs from running. GitHub reports the total generated count in the error
+  message: "Matrix generates N entries. Limited to 256."
+
+  This limit applies equally to GitHub-hosted and self-hosted runners and
+  cannot be increased by contacting support.
+fix: |
+  The 256-job-per-run limit is hard and cannot be increased. Options:
+
+  1. Split across multiple workflow files, each handling a subset of targets.
+     Trigger them from a parent coordinator workflow or via separate triggers.
+
+  2. Reduce matrix dimensions: test only meaningful combinations using
+     explicit include: lists rather than full Cartesian products. Not every
+     OS x language x version triplet needs to be tested.
+
+  3. Chunk using workflow_dispatch fan-out: a generator job creates N chunks
+     of at most 256 items and dispatches sub-workflow runs per chunk via
+     repository_dispatch or workflow_dispatch API calls.
+
+  4. Use a single job with a shell loop for some dimensions: instead of
+     separate matrix jobs per version, loop over versions inside one job step.
+     Sacrifices parallelism but avoids the limit entirely.
+fix_code:
+  - language: yaml
+    label: "Broken — Cartesian product silently grows past 256 as versions are added"
+    code: |
+      strategy:
+        matrix:
+          os: [ubuntu-22.04, ubuntu-24.04, windows-2022, macos-14, macos-15]
+          node: [18, 20, 22, 23]
+          python: ['3.9', '3.10', '3.11', '3.12', '3.13']
+          # 5 x 4 x 5 = 100 jobs today — fine, but adding node 24 pushes to 125,
+          # adding python 3.14 pushes to 150, and so on until 256 is silently hit
+
+  - language: yaml
+    label: "Fixed — explicit include list tests only meaningful combinations"
+    code: |
+      strategy:
+        matrix:
+          include:
+            # Test LTS node on primary OS with latest stable Python
+            - os: ubuntu-24.04
+              node: 20
+              python: '3.12'
+            - os: ubuntu-24.04
+              node: 22
+              python: '3.12'
+            # Windows only gets the most recent LTS
+            - os: windows-2022
+              node: 20
+              python: '3.11'
+            # macOS gets one combination
+            - os: macos-15
+              node: 20
+              python: '3.12'
+          # Total: 4 jobs instead of 100+ from full Cartesian product
+
+  - language: yaml
+    label: "Defensive — validate dynamic matrix size before passing to strategy"
+    code: |
+      jobs:
+        generate-matrix:
+          runs-on: ubuntu-latest
+          outputs:
+            matrix: ${{ steps.gen.outputs.matrix }}
+          steps:
+            - id: gen
+              run: |
+                MATRIX=$(cat test-matrix.json)
+                COUNT=$(echo "$MATRIX" | jq '.include | length')
+                if [ "$COUNT" -gt 256 ]; then
+                  echo "::error::Matrix has $COUNT entries (limit: 256). Split into multiple workflows."
+                  exit 1
+                fi
+                echo "matrix=$MATRIX" >> "$GITHUB_OUTPUT"
+
+        test:
+          needs: generate-matrix
+          strategy:
+            matrix: ${{ fromJSON(needs.generate-matrix.outputs.matrix) }}
+          runs-on: ${{ matrix.os }}
+          steps:
+            - run: echo "Testing ${{ matrix.os }} / ${{ matrix.version }}"
+prevention:
+  - "Before adding a new matrix axis, calculate the new total job count — it must stay at or below 256."
+  - "For dynamic matrices (fromJSON), validate the output list length in the generator job and fail fast if > 256."
+  - "Prefer explicit include: lists over full Cartesian products when not all dimension combinations are meaningful."
+  - "Monitor matrix job counts over time: a previously-safe matrix silently crosses 256 as new versions are added."
+  - "Document the current job count in a comment next to the matrix block so reviewers notice when PRs push it higher."
+docs:
+  - url: "https://docs.github.com/en/actions/reference/limits"
+    label: "GitHub Actions Limits — Job Matrix: 256 jobs per workflow run"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow"
+    label: "GitHub Docs — Using a matrix for your jobs"

package/errors/permissions-auth/permissions-auth-070.yml

@@ -0,0 +1,136 @@
+id: permissions-auth-070
+title: "GITHUB_TOKEN packages:write Cannot Delete GitHub Container Registry Packages"
+category: permissions-auth
+severity: error
+tags:
+  - github-packages
+  - ghcr
+  - container-registry
+  - packages-delete
+  - permissions
+  - pat
+patterns:
+  - regex: 'delete.*package.*403|package.*delete.*forbidden'
+    flags: 'i'
+  - regex: 'Resource not accessible by integration'
+    flags: 'i'
+error_messages:
+  - "Resource not accessible by integration"
+  - "HttpError: Resource not accessible by integration"
+  - "403 Forbidden"
+root_cause: |
+  GitHub Container Registry (ghcr.io) and other granular-permission package
+  registries (npm, NuGet, RubyGems on ghpr) use package-level access control
+  that is separate from repository permissions. The GITHUB_TOKEN workflow
+  permission block supports packages: write, which grants the ability to:
+  - Publish (push) new package versions
+  - Update package metadata and visibility
+
+  However, packages: write does NOT grant the ability to DELETE package
+  versions. Deletion of granular-permission packages requires the delete:packages
+  scope, which exists only on classic personal access tokens (PATs) — there is
+  no equivalent permission in the GITHUB_TOKEN fine-grained model.
+
+  As a result, workflows that use actions/delete-package-versions (or make
+  direct REST API calls to DELETE /user/packages/{type}/{name}/versions/{id}
+  or DELETE /orgs/{org}/packages/{type}/{package_name}/versions/{id}) always
+  fail with 403 "Resource not accessible by integration" even with:
+    permissions:
+      packages: write
+
+  Note: Repository-scoped packages (Apache Maven, legacy Gradle) that inherit
+  repository permissions may behave differently — deletion can work via the
+  repo admin role. Container Registry packages always use granular permissions.
+fix: |
+  Replace GITHUB_TOKEN with a token that carries delete:packages authority.
+
+  Option 1 (recommended for orgs): GitHub App token
+  - Create a GitHub App with "Packages: Read & Write" and "Packages: Admin"
+    permissions
+  - Install the app on the org or repo
+  - Use actions/create-github-app-token to generate a token in the workflow
+  - Pass the token to the deletion step
+
+  Option 2 (simpler for personal/small-team repos): Classic PAT
+  - Generate a classic PAT (Settings > Developer settings > Personal access
+    tokens > Tokens (classic)) with the delete:packages scope
+  - Store as a repository or organization secret
+  - Reference the secret in the deletion step
+
+  Option 3 (repo-scoped packages only — Apache Maven, Gradle):
+  - Ensure the package uses repository-scoped permissions (not granular)
+  - Grant the workflow admin access to the repository
+  - This does NOT apply to ghcr.io container images, which always require
+    a PAT or App approach for deletion
+fix_code:
+  - language: yaml
+    label: "Broken — GITHUB_TOKEN packages:write cannot delete container images"
+    code: |
+      permissions:
+        packages: write  # Grants publish access but NOT delete access
+
+      jobs:
+        cleanup:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Delete old versions
+              uses: actions/delete-package-versions@v5
+              with:
+                package-name: my-image
+                package-type: container
+                min-versions-to-keep: 5
+                token: ${{ secrets.GITHUB_TOKEN }}  # Fails with 403 for container packages
+
+  - language: yaml
+    label: "Fixed — classic PAT with delete:packages scope"
+    code: |
+      permissions:
+        packages: write
+
+      jobs:
+        cleanup:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Delete old versions
+              uses: actions/delete-package-versions@v5
+              with:
+                package-name: my-image
+                package-type: container
+                min-versions-to-keep: 5
+                # Classic PAT must have: write:packages + delete:packages scopes
+                token: ${{ secrets.PAT_DELETE_PACKAGES }}
+
+  - language: yaml
+    label: "Fixed — GitHub App token (recommended for organizations)"
+    code: |
+      jobs:
+        cleanup:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Generate GitHub App token
+              id: app-token
+              uses: actions/create-github-app-token@v1
+              with:
+                app-id: ${{ vars.PACKAGE_CLEANUP_APP_ID }}
+                private-key: ${{ secrets.PACKAGE_CLEANUP_APP_KEY }}
+
+            - name: Delete old container image versions
+              uses: actions/delete-package-versions@v5
+              with:
+                package-name: my-image
+                package-type: container
+                min-versions-to-keep: 5
+                token: ${{ steps.app-token.outputs.token }}
+prevention:
+  - "Never assume packages:write grants deletion rights — it only covers publish and metadata operations."
+  - "Provision a dedicated classic PAT or GitHub App with package admin access for all cleanup/retention workflows."
+  - "Document which secrets are needed for deletion workflows so maintainers do not accidentally replace them with GITHUB_TOKEN."
+  - "Audit all uses of actions/delete-package-versions in your org to confirm each workflow uses an appropriate token."
+  - "Prefer GitHub App tokens over classic PATs for org workflows — PAT credentials are tied to a specific user account."
+docs:
+  - url: "https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages"
+    label: "GitHub Docs — About permissions for GitHub Packages (granular vs repository-scoped)"
+  - url: "https://github.com/actions/delete-package-versions"
+    label: "actions/delete-package-versions — token requirements"
+  - url: "https://docs.github.com/en/rest/packages/packages"
+    label: "GitHub REST API — Packages DELETE endpoints"

package/errors/runner-environment/runner-environment-219.yml

@@ -0,0 +1,120 @@
+id: runner-environment-219
+title: 'pnpm/action-setup@v6.0.0 Always Installs pnpm v11 Regardless of Requested Version'
+category: runner-environment
+severity: error
+tags:
+  - pnpm
+  - action-setup
+  - pnpm-v11
+  - version-mismatch
+  - path-priority
+  - lockfile
+patterns:
+  - regex: 'ERR_PNPM_UNSUPPORTED_ENGINE.*Unsupported environment'
+    flags: 'i'
+  - regex: 'Expected version:.*Got:.*11\.'
+    flags: 'i'
+  - regex: 'ERR_PNPM_LOCKFILE_CONFIG_MISMATCH.*frozen installation'
+    flags: 'i'
+  - regex: 'ERR_PNPM_BROKEN_LOCKFILE.*expected a single document'
+    flags: 'i'
+error_messages:
+  - "ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)"
+  - "Expected version: 10\n  Got: 11.0.0-beta.4-1"
+  - "ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen installation. The current \"overrides\" configuration doesn't match the value found in the lockfile"
+  - "ERR_PNPM_BROKEN_LOCKFILE  The lockfile at \"<path>/pnpm-lock.yaml\" is broken: expected a single document in the stream, but found more"
+root_cause: |
+  pnpm/action-setup@v6.0.0 introduced a "self-managed" bootstrap mechanism where
+  pnpm installs itself using pnpm. The action downloads a bootstrap binary (pnpm v11)
+  and uses it to self-update to the requested version. However, in v6.0.0 through
+  v6.0.7, a PATH priority bug caused the bootstrap binary to shadow the correctly
+  installed version at runtime:
+
+    addPath(path.join(pnpmHome, 'bin'))  // correct binary installed here
+    addPath(pnpmHome)                    // bootstrap v11 binary lives here
+
+  Because addPath prepends in reverse call order, PNPM_HOME (containing the bootstrap
+  v11 binary) was always first on PATH, shadowing PNPM_HOME/bin (containing the
+  self-updated target version). Any workflow step that ran `pnpm` therefore used v11
+  regardless of the `version:` input.
+
+  Side effects of this bug:
+  1. workflows specifying `version: 10` run with pnpm v11, triggering
+     ERR_PNPM_UNSUPPORTED_ENGINE if engines.pnpm is set in package.json
+  2. pnpm v11 writes `configDependencies` blocks into pnpm-lock.yaml during any
+     install, corrupting the lockfile from pnpm v10's perspective; subsequent
+     `--frozen-lockfile` installs fail with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH
+  3. When using `package_json_file:` input, the wrong version is read because pnpm
+     v11 changed lockfile format, causing ERR_PNPM_BROKEN_LOCKFILE when the v11
+     bootstrap writes partial YAML to the lockfile before the correct version takes
+     over
+
+  The fix (addPath call order swap) was merged in PR #230 and released in v6.0.1.
+  A separate bootstrap bundle update for pnpm 11.0.0-rc.2 was released in v6.0.3.
+  Full stability for most scenarios reached v6.0.8.
+fix: |
+  Upgrade to pnpm/action-setup@v6.0.8 or later. The PATH priority bug and
+  configDependencies lockfile corruption are fixed in v6.0.1+.
+
+  If you cannot upgrade, pin back to v5:
+
+    - uses: pnpm/action-setup@v5
+      with:
+        version: 10
+
+  If you are on v6 and seeing lockfile corruption: delete the corrupted
+  pnpm-lock.yaml and regenerate it with the correct pnpm version locally
+  before re-running CI. Do NOT run pnpm install in the corrupted-lockfile
+  state as it will write a v11 lockfile into your repo.
+fix_code:
+  - language: yaml
+    label: 'Broken — pnpm/action-setup@v6.0.0 installs v11 regardless of version input'
+    code: |
+      - uses: pnpm/action-setup@v6      # v6.0.0: PATH bug installs v11 always
+        with:
+          version: 10                   # Ignored — v11 ends up on PATH
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: 'pnpm'
+      - run: pnpm install --frozen-lockfile
+        # Fails: ERR_PNPM_LOCKFILE_CONFIG_MISMATCH or ERR_PNPM_UNSUPPORTED_ENGINE
+
+  - language: yaml
+    label: 'Fixed — upgrade to v6.0.8+ (PATH priority bug resolved)'
+    code: |
+      - uses: pnpm/action-setup@v6.0.8  # v6.0.8: PATH priority fixed, stable
+        with:
+          version: 10
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: 'pnpm'
+      - run: pnpm install --frozen-lockfile
+
+  - language: yaml
+    label: 'Alternative fix — pin back to v5 until v6 is stable for your project'
+    code: |
+      - uses: pnpm/action-setup@v5
+        with:
+          version: 10
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: 'pnpm'
+      - run: pnpm install --frozen-lockfile
+
+prevention:
+  - 'Pin pnpm/action-setup to a specific minor/patch version (e.g. @v6.0.8) rather than @v6 to avoid silent major-bump breakage from Dependabot.'
+  - 'After upgrading pnpm/action-setup, verify `pnpm --version` in the first step matches the requested version before running install.'
+  - 'If pnpm-lock.yaml is corrupted by this bug, delete it and regenerate locally with the correct pnpm version — do not attempt to fix by re-running CI.'
+  - 'Set `engines.pnpm` in package.json to detect unexpected version mismatches early with ERR_PNPM_UNSUPPORTED_ENGINE rather than silent wrong-behavior.'
+docs:
+  - url: 'https://github.com/pnpm/action-setup/issues/225'
+    label: 'pnpm/action-setup#225 — v6.0.0 always installs v11 (51 reactions)'
+  - url: 'https://github.com/pnpm/action-setup/issues/226'
+    label: 'pnpm/action-setup#226 — v6.0.0 modifies pnpm-lock.yaml (lockfile corruption)'
+  - url: 'https://github.com/pnpm/action-setup/pull/230'
+    label: 'pnpm/action-setup#230 — Fix: swap addPath call order (merged)'
+  - url: 'https://github.com/pnpm/action-setup/releases'
+    label: 'pnpm/action-setup releases — v6.0.1 contains the PATH fix'

package/errors/runner-environment/runner-environment-220.yml

@@ -0,0 +1,123 @@
+id: runner-environment-220
+title: 'Node.js 20 JavaScript Actions Runtime Deprecated — Forced Migration to Node.js 24 (June 2026)'
+category: runner-environment
+severity: warning
+tags:
+  - nodejs
+  - node20
+  - node24
+  - javascript-actions
+  - deprecation
+  - runtime
+  - actions-upgrade
+patterns:
+  - regex: 'Node\.js 20 actions are deprecated'
+    flags: 'i'
+  - regex: 'running on Node\.js 20 and may not work as expected'
+    flags: 'i'
+  - regex: 'Actions will be forced to run with Node\.js 24 by default'
+    flags: 'i'
+  - regex: 'FORCE_JAVASCRIPT_ACTIONS_TO_NODE24'
+    flags: 'i'
+error_messages:
+  - "Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected: actions/deploy-pages@v4."
+  - "Actions will be forced to run with Node.js 24 by default starting June 2nd, 2026."
+  - "Please check if updated versions of these actions are available that support Node.js 24."
+root_cause: |
+  GitHub Actions JavaScript action runtimes follow Node.js LTS lifecycle.
+  Node.js 20 reached end-of-life in April 2026, and GitHub deprecated it as a
+  supported JavaScript actions runtime in September 2025:
+
+  - Sept 2025: Deprecation announced. Warning annotation added to workflow runs.
+  - Feb 2026: Runner v2.322+ begins emitting "Node.js 20 actions are deprecated"
+    annotation for any action whose package.json specifies "main" with runs.using: node20.
+  - June 2, 2026: Forced migration. Actions using node20 runtime are automatically
+    upgraded to run on Node.js 24 unless ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true
+    is set.
+
+  Actions affected are those that declare `runs.using: node20` in their action.yml.
+  This is a property of the action itself, not the workflow caller. Common examples
+  that shipped with node20 and required major version bumps:
+    - actions/deploy-pages@v4 → upgrade to @v5
+    - actions/upload-pages-artifact@v3 → upgrade to @v4
+    - Third-party actions on older major versions
+
+  The warning does NOT cause workflow failures in most cases — the runner upgrades
+  the action to run under Node.js 24 automatically starting June 2, 2026. However:
+  1. Actions using APIs removed or changed between Node.js 20 and 24 (e.g., internal
+     crypto or buffer APIs) may silently produce wrong results or throw runtime errors
+  2. The warning annotation shows up in every workflow run's annotation panel,
+     cluttering the UI and masking real warnings
+  3. Some security-conscious pipelines treat any annotation as a build failure
+     via fail-on-annotations settings
+fix: |
+  1. Identify which actions in your workflow are still on node20 runtime:
+     Look for "Node.js 20 actions are deprecated" annotations in the Workflow Annotations
+     panel (gear icon next to workflow run summary).
+
+  2. Upgrade the pinned version of the affected action to a release that uses node24:
+       - actions/deploy-pages@v4 → @v5
+       - actions/upload-pages-artifact@v3 → @v4
+       - For third-party actions: check their releases for "node24" or "Node.js 24" mentions
+
+  3. If no node24 version of a required action exists yet, set the opt-out env var
+     as a temporary measure (not recommended for production):
+       env:
+         ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: 'true'
+
+  4. To opt into Node.js 24 early for a specific workflow (before June 2 deadline):
+       env:
+         FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: 'true'
+fix_code:
+  - language: yaml
+    label: 'Broken — actions/deploy-pages@v4 uses node20 runtime (shows deprecation warning)'
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Deploy to GitHub Pages
+              uses: actions/deploy-pages@v4    # node20 runtime — triggers deprecation warning
+
+  - language: yaml
+    label: 'Fixed — upgrade to v5 which uses node24 runtime'
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Deploy to GitHub Pages
+              uses: actions/deploy-pages@v5    # node24 runtime — no deprecation warning
+
+  - language: yaml
+    label: 'Temporary opt-out — allow node20 actions to run (not recommended long-term)'
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          env:
+            ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: 'true'   # Suppresses forced upgrade
+          steps:
+            - uses: actions/deploy-pages@v4    # Still runs on node20 (insecure)
+
+  - language: yaml
+    label: 'Find all node20 actions in your workflow via actionlint annotation grep'
+    code: |
+      # Run actionlint locally or in CI to list all outdated action runtimes:
+      # actionlint .github/workflows/*.yml | grep "node20"
+      #
+      # Or use gh CLI to scan your workflow annotation after a run:
+      # gh run view <run-id> --json annotations --jq '.annotations[] | select(.message | contains("Node.js 20"))'
+
+prevention:
+  - 'Subscribe to the GitHub Actions changelog (https://github.blog/changelog/label/github-actions/) to catch runtime deprecation announcements early.'
+  - 'Use Dependabot for GitHub Actions to get automatic PRs when new major versions of actions are released with updated runtimes.'
+  - 'Run actionlint in CI — it can detect actions using deprecated node runtime versions.'
+  - 'When pinning third-party actions to SHA hashes, periodically check if newer major versions with updated runtimes have been released.'
+docs:
+  - url: 'https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/'
+    label: 'GitHub Changelog — Deprecation of Node.js 20 on GitHub Actions runners (Sept 2025)'
+  - url: 'https://github.com/actions/deploy-pages/issues/410'
+    label: 'actions/deploy-pages#410 — Support Node.js 24 (36 reactions)'
+  - url: 'https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runsusing'
+    label: 'GitHub Docs — runs.using in action.yml (supported runtime versions)'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@htekdev/actions-debugger",
-  "version": "1.0.119",
+  "version": "1.0.121",
   "description": "65+ real GitHub Actions errors, queryable by agents. CLI + MCP server + Copilot skills + error database.",
   "type": "module",
   "main": "./dist/index.js",