@htekdev/actions-debugger 1.0.132 → 1.0.134

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

@@ -0,0 +1,100 @@
+id: caching-artifacts-078
+title: '`upload-artifact/merge` aborts with "Failed to DeleteArtifact: (404) Not Found" when a delete is retried after a transient server error'
+category: caching-artifacts
+severity: error
+tags:
+  - upload-artifact
+  - merge
+  - delete-merged
+  - 404
+  - idempotent-delete
+  - artifact-merge
+patterns:
+  - regex: 'Failed to DeleteArtifact.*non-retryable error.*404|DeleteArtifact.*404.*Not Found'
+    flags: 'i'
+  - regex: 'Received non-retryable error.*Failed request.*404.*artifact not found'
+    flags: 'i'
+error_messages:
+  - "Error: Failed to DeleteArtifact: Received non-retryable error: Failed request: (404) Not Found: artifact not found"
+  - "Attempt 1 of 5 failed with error: Unexpected token '<', \"<!DOCTYPE \"... is not valid JSON. Retrying request in 3000 ms..."
+root_cause: |
+  When using `actions/upload-artifact/merge@v6` (or later) with `delete-merged: true`,
+  the action deletes each source artifact after merging them into the combined artifact.
+  If a delete request encounters a transient server error (e.g., a malformed HTML response
+  instead of JSON — indicated by "Unexpected token '<'"), the action retries the delete.
+
+  If the first delete request was actually processed by the server before the error was
+  returned to the client, the artifact is already gone. The retry then receives a 404
+  Not Found, which `DeleteArtifact` treats as a **non-retryable fatal error** and
+  immediately aborts the job.
+
+  Because `delete-merged: true` is destructive — source artifacts have already been
+  deleted by this point — retrying the entire job from scratch is impossible, as the
+  source artifacts no longer exist.
+
+  Root bug: `DeleteArtifact` should treat 404 as a success (idempotent delete — the
+  artifact not existing IS the desired state). This is tracked in upload-artifact#751
+  (open, Jan 2026). No server-side fix has been released as of June 2026.
+fix: |
+  Option 1 — Add `continue-on-error: true` to the merge step so that the 404 error
+  does not fail the overall job. Verify that the merge artifact was created successfully
+  before relying on this workaround, since `continue-on-error` also swallows real
+  failures.
+
+  Option 2 — Set `delete-merged: false` and handle deletion of source artifacts in a
+  separate step with explicit error handling (e.g., `gh api` with `--fail-with-body` and
+  a conditional step that ignores 404 exit codes).
+
+  Option 3 — Wrap the merge step in a retry loop using `nick-invision/retry` or a
+  shell retry, but note that re-running the merge after partial deletion will fail because
+  source artifacts are gone. Prevention is better than recovery here.
+
+  Monitor upload-artifact#751 for an upstream fix that makes 404 on DeleteArtifact
+  idempotent/non-fatal.
+fix_code:
+  - language: yaml
+    label: 'continue-on-error workaround — prevents 404 from failing the job'
+    code: |
+      - name: Merge artifacts
+        uses: actions/upload-artifact/merge@v6
+        # ⚠️ Workaround: continue-on-error so a DeleteArtifact 404 does not fail the job.
+        # Also swallows real upload failures — add a downstream step to verify the
+        # merged artifact exists if reliability matters.
+        continue-on-error: true
+        with:
+          name: merged-results
+          pattern: partial-results-*
+          delete-merged: true
+  - language: yaml
+    label: 'delete-merged: false with manual deletion that ignores 404'
+    code: |
+      - name: Merge artifacts (no auto-delete)
+        uses: actions/upload-artifact/merge@v6
+        with:
+          name: merged-results
+          pattern: partial-results-*
+          delete-merged: false   # ✅ Suppress automatic deletion
+
+      # Manually delete source artifacts, ignoring 404 responses (already deleted)
+      - name: Delete source artifacts
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          for artifact_id in $(gh api repos/${{ github.repository }}/actions/artifacts \
+            --jq '.artifacts[] | select(.name | startswith("partial-results-")) | .id'); do
+            gh api --method DELETE \
+              repos/${{ github.repository }}/actions/artifacts/$artifact_id \
+              --silent || echo "Artifact $artifact_id already deleted (404) — ignoring"
+          done
+prevention:
+  - 'Avoid `delete-merged: true` in critical CI pipelines until upload-artifact#751 is fixed — use manual deletion with 404 tolerance instead'
+  - 'Add `continue-on-error: true` to merge steps as a temporary workaround for the 404 abort'
+  - 'Keep source artifacts available by using `delete-merged: false` until the upstream fix lands'
+  - 'Monitor actions/upload-artifact#751 for a release that treats DeleteArtifact 404 as success'
+docs:
+  - url: 'https://github.com/actions/upload-artifact/issues/751'
+    label: 'upload-artifact#751: DeleteArtifact should not consider a 404 response an error (open, Jan 2026)'
+  - url: 'https://github.com/actions/upload-artifact/blob/main/merge/README.md'
+    label: 'actions/upload-artifact merge action README — delete-merged option'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-workflow-data-as-artifacts'
+    label: 'GitHub Docs: Storing workflow data as artifacts'

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

@@ -0,0 +1,95 @@
+id: caching-artifacts-079
+title: '`setup-node@v5` auto-enables caching when `packageManager` is set in `package.json` — post-run fails with "Path Validation Error" if dependencies are not installed'
+category: caching-artifacts
+severity: error
+tags:
+  - setup-node
+  - caching
+  - packageManager
+  - path-validation
+  - post-run
+  - setup-node-v5
+  - automatic-caching
+patterns:
+  - regex: 'Path Validation Error.*Path.*specified.*action.*caching.*do.*not exist'
+    flags: 'i'
+  - regex: 'Path.*specified.*action.*caching.*do.{0,5}not exist.*no cache'
+    flags: 'i'
+error_messages:
+  - "Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved."
+root_cause: |
+  Starting with `actions/setup-node@v5`, automatic caching is enabled **by default**
+  whenever a `packageManager` field is present in the project's `package.json` file —
+  even if the workflow does not explicitly configure caching via the `cache:` input.
+
+  This means jobs that merely run linting, type-checking, or any step that does not
+  execute `npm install` / `yarn install` / `pnpm install` will still attempt to cache
+  the package manager's dependency directory in the post-run cleanup step. Because no
+  `install` was run, the expected cache paths (e.g., `~/.npm`, `~/.yarn/cache`,
+  `~/.pnpm-store`) do not exist. The toolkit's path validation then emits:
+  "Path Validation Error: Path(s) specified in the action for caching do(es) not exist"
+  and **fails the job step**, turning a previously green run red.
+
+  **Why this surprises developers:**
+  - The workflow never explicitly enables caching — the presence of `packageManager`
+    in `package.json` is the invisible trigger.
+  - The error appears in the **post-run** cleanup step, not in the setup step where
+    caching is configured, making it harder to trace.
+  - Workflows that have always worked (no `cache:` input) start failing after upgrading
+    from `setup-node@v4` to `setup-node@v5`.
+
+  **Resolution:** `setup-node@v6` (released Oct 2025) changed the default so automatic
+  caching only applies to npm; yarn/pnpm caching is now opt-in. Upgrading to v6 or
+  explicitly disabling the cache in v5 resolves the issue.
+  Source: setup-node#1363 (5 reactions, closed Oct 2025 via v6 release).
+fix: |
+  Option 1 (recommended) — Upgrade to `actions/setup-node@v6`. The v6 release limits
+  automatic caching to npm only; yarn and pnpm caching require explicit `cache: yarn`
+  or `cache: pnpm` input.
+
+  Option 2 — Disable automatic caching in v5 by setting `package-manager-cache: false`.
+  Use this if you cannot upgrade to v6 immediately.
+
+  Option 3 — Ensure dependencies are installed in every job that uses `setup-node@v5`.
+  If the job only needs Node for tooling (lint, type-check, etc.), run a minimal
+  `npm ci --ignore-scripts` or equivalent before the setup post-run fires.
+fix_code:
+  - language: yaml
+    label: 'Upgrade to setup-node@v6 — fixes automatic caching defaults'
+    code: |
+      # ✅ Recommended: v6 only auto-caches npm, not yarn/pnpm
+      - uses: actions/setup-node@v6
+        with:
+          node-version: '22'
+          # No cache: input needed — auto-caching is npm-only in v6
+  - language: yaml
+    label: 'Disable automatic caching in v5 with package-manager-cache: false'
+    code: |
+      # ✅ Workaround for setup-node@v5: suppress auto-caching
+      - uses: actions/setup-node@v5
+        with:
+          node-version: '22'
+          package-manager-cache: false   # Disables packageManager-triggered auto-cache
+      - run: npx eslint src/
+  - language: yaml
+    label: 'Opt in to caching explicitly for jobs that do install dependencies'
+    code: |
+      # ✅ Jobs that do install: use explicit cache input instead of relying on auto-detect
+      - uses: actions/setup-node@v6
+        with:
+          node-version: '22'
+          cache: 'npm'            # Explicit opt-in — cache only when deps are installed
+      - run: npm ci
+      - run: npm test
+prevention:
+  - 'Upgrade to `setup-node@v6` which fixes the over-eager auto-caching of yarn/pnpm in v5'
+  - 'In v5, always set `package-manager-cache: false` for jobs that do not run `install`'
+  - 'Check `package.json` for a `packageManager` field — its presence triggers auto-caching in v5 even without an explicit `cache:` input'
+  - 'Run lint, type-check, and audit jobs without setup-node caching to keep them fast and avoid phantom cache failures'
+docs:
+  - url: 'https://github.com/actions/setup-node/issues/1363'
+    label: 'setup-node#1363: v5 fails with Path Validation Error in Post Run steps (5 reactions, resolved in v6)'
+  - url: 'https://github.com/actions/setup-node/releases/tag/v6.0.0'
+    label: 'setup-node v6.0.0 release notes — auto-caching limited to npm'
+  - url: 'https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#caching-packages-data'
+    label: 'setup-node docs: Caching packages data'

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

@@ -0,0 +1,140 @@
+id: known-unsolved-077
+title: '`fromJSON()` array nested inside a matrix object does not expand — resolves as literal "Array" or raw JSON string'
+category: known-unsolved
+severity: silent-failure
+tags:
+  - matrix
+  - fromJSON
+  - dynamic-matrix
+  - object
+  - array-expansion
+  - known-limitation
+  - silent-failure
+patterns:
+  - regex: 'fromJSON\(needs\.\w+\.outputs\.'
+    flags: 'i'
+  - regex: 'matrix\.\w+\.\w+.*\bArray\b|\bArray\b.*matrix\.'
+    flags: 'i'
+error_messages:
+  - "echo x86_64 Array"
+  - 'matrix.component.distro = Array'
+  - 'matrix.component.distro = ["el8","el9"]'
+root_cause: |
+  GitHub Actions supports expanding a JSON array into matrix rows when `fromJSON()` is
+  used **at the top level** of a matrix dimension:
+  ```yaml
+  strategy:
+    matrix:
+      version: ${{ fromJSON(needs.setup.outputs.versions) }}  # ✅ expands to N rows
+  ```
+
+  However, when the array is nested inside a matrix **object** (i.e., as a value within
+  one of the items of a matrix dimension), `fromJSON()` does NOT expand it into rows.
+  Instead, the expression resolves to:
+  - The literal string `"Array"` when `fromJSON()` is used (type-1 pattern)
+  - The raw JSON string (e.g., `["el8","el9"]`) when the output is used directly (type-2 pattern)
+
+  **Failing patterns:**
+  ```yaml
+  # Type 1 — fromJSON inside a matrix object value
+  matrix:
+    component:
+      - name: rhel
+        distro: ${{ fromJSON(needs.setup.outputs.rpms) }}   # ❌ becomes "Array"
+
+  # Type 2 — raw JSON string inside a matrix object value
+  matrix:
+    component:
+      - name: rhel
+        distro: ${{ needs.setup.outputs.rpms }}              # ❌ becomes the raw JSON string
+  ```
+
+  The expansion mechanism only applies when the entire matrix dimension value is a
+  `fromJSON()` call returning an array. Nesting breaks the expansion because the runner
+  evaluates the object first and cannot retroactively fan out a single object item into
+  multiple rows.
+
+  This is a documented limitation. GitHub's matrix engine does not support nested array
+  expansion within object-typed matrix dimensions. The issue is tracked in
+  actions/runner#3794 (open since Apr 2025, no planned fix).
+
+  **Why this is confusing:**
+  The `fromJSON()` approach works perfectly when the array IS the entire dimension:
+  `matrix: version: ${{ fromJSON(needs.setup.outputs.versions) }}`. Developers naturally
+  try to reuse the same pattern inside object dimensions and get silently wrong values —
+  the job runs to completion but with a single row containing "Array" instead of N rows.
+fix: |
+  Restructure the matrix so that the dynamic array is the TOP-LEVEL matrix dimension,
+  not nested inside an object. Move any additional object properties into the
+  `matrix.include` block to pair them with each array element.
+
+  If you need multiple outputs to compose a matrix, pre-process them into a combined
+  JSON array in an upstream job step and pass the combined output as a single
+  `fromJSON()` expression.
+fix_code:
+  - language: yaml
+    label: 'Move the dynamic array to the top-level dimension — this expands correctly'
+    code: |
+      jobs:
+        setup:
+          runs-on: ubuntu-latest
+          outputs:
+            rpms: ${{ steps.distros.outputs.rpms }}
+            debs: ${{ steps.distros.outputs.debs }}
+          steps:
+            - id: distros
+              run: |
+                echo 'rpms=["el8","el9"]' >> "$GITHUB_OUTPUT"
+                echo 'debs=["focal","jammy","noble"]' >> "$GITHUB_OUTPUT"
+
+        build:
+          needs: setup
+          runs-on: ubuntu-latest
+          strategy:
+            matrix:
+              # ✅ distro is the top-level dimension — fromJSON expands to N rows
+              distro: ${{ fromJSON(needs.setup.outputs.rpms) }}
+          steps:
+            - run: echo "Building for ${{ matrix.distro }}"
+  - language: yaml
+    label: 'Pre-combine multiple arrays into a single include list in the upstream job'
+    code: |
+      jobs:
+        setup:
+          runs-on: ubuntu-latest
+          outputs:
+            matrix: ${{ steps.build-matrix.outputs.matrix }}
+          steps:
+            - id: build-matrix
+              run: |
+                # Build a combined include list from multiple arrays
+                matrix=$(python3 -c "
+                import json, sys
+                rpms = ['el8', 'el9']
+                debs = ['focal', 'jammy', 'noble']
+                include = [{'family': 'rhel', 'distro': d} for d in rpms] + \
+                          [{'family': 'debian', 'distro': d} for d in debs]
+                print(json.dumps({'include': include}))
+                ")
+                echo "matrix=$matrix" >> "$GITHUB_OUTPUT"
+
+        build:
+          needs: setup
+          runs-on: ubuntu-latest
+          strategy:
+            # ✅ fromJSON on a single combined matrix object with include list
+            matrix: ${{ fromJSON(needs.setup.outputs.matrix) }}
+          steps:
+            - run: echo "Building ${{ matrix.family }} for ${{ matrix.distro }}"
+prevention:
+  - 'Never use `fromJSON()` as the value of a property inside a matrix object — it will not expand to multiple rows'
+  - 'Only use `fromJSON()` when the array IS the entire dimension value (e.g., `matrix.version: ${{ fromJSON(...) }}`)'
+  - 'When combining multi-dimensional dynamic matrices, pre-compute a combined `include` list in an upstream job'
+  - 'Verify matrix expansion by adding a `- run: echo ${{ toJSON(matrix) }}` debug step; "Array" in the output confirms the bug'
+docs:
+  - url: 'https://github.com/actions/runner/issues/3794'
+    label: 'actions/runner#3794: Array outputs not understood by matrix when nested inside object (open, Apr 2025)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow#using-a-matrix-strategy'
+    label: 'GitHub Docs: Using a matrix strategy'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#fromjson'
+    label: 'GitHub Docs: fromJSON expression function'

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

@@ -0,0 +1,91 @@
+id: known-unsolved-078
+title: 'Copilot agent branches not available in `workflow_dispatch` branch picker — cannot manually target Copilot branches'
+category: known-unsolved
+severity: limitation
+tags:
+  - workflow_dispatch
+  - copilot-agent
+  - branch-picker
+  - manual-trigger
+  - github-copilot
+  - ui-limitation
+patterns:
+  - regex: 'copilot.*branch.*not.*available|copilot.*branch.*missing.*dispatch'
+    flags: 'i'
+  - regex: 'workflow_dispatch.*copilot.*branch|copilot.*agent.*branch.*trigger'
+    flags: 'i'
+error_messages:
+  - "# No error message — Copilot agent branches simply do not appear in the branch selector"
+root_cause: |
+  When GitHub Copilot coding agent creates a branch to work on an assigned task,
+  the branch uses a namespaced prefix (`copilot/` by default, e.g.,
+  `copilot/fix-issue-123`). These branches are created and owned by the Copilot agent.
+
+  The GitHub Actions UI for `workflow_dispatch` presents a branch picker dropdown
+  that allows users to select which branch to run the workflow against. However,
+  Copilot agent branches are NOT included in this branch picker.
+
+  This is a UI-level platform limitation: GitHub filters the branch list shown in the
+  `workflow_dispatch` selector and excludes Copilot-owned branches from the list.
+  There is no documented API reason why this would be necessary — the branches exist
+  and are valid git refs — but the UI omits them.
+
+  As a workaround, the GitHub CLI or REST API CAN be used to trigger a
+  `workflow_dispatch` run targeting a Copilot branch by supplying the `ref` parameter
+  explicitly (bypassing the UI picker).
+
+  This issue was reported in runner#4246 (Feb 2026, 15 reactions) and remained open
+  as of June 2026. No ETA for a fix has been provided.
+
+  Note: This is a separate issue from Copilot agent PR workflows requiring approval
+  before running (triggers-027). That entry covers automatic workflows on Copilot PRs;
+  this entry covers the inability to manually dispatch TO a Copilot branch via the UI.
+fix: |
+  There is no UI fix — Copilot agent branches cannot be selected in the GitHub Actions
+  web interface workflow_dispatch branch picker.
+
+  **Workaround: use the GitHub CLI to trigger workflow_dispatch with an explicit ref:**
+  ```bash
+  gh workflow run <workflow-file.yml> --ref copilot/fix-issue-123
+  ```
+
+  **Workaround: use the GitHub REST API:**
+  ```bash
+  curl -X POST \
+    -H "Authorization: Bearer $GITHUB_TOKEN" \
+    -H "Accept: application/vnd.github+json" \
+    https://api.github.com/repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches \
+    -d '{"ref":"copilot/fix-issue-123","inputs":{}}'
+  ```
+
+  Both the CLI and API accept any valid branch ref, including Copilot branches,
+  even though the UI does not display them.
+fix_code:
+  - language: yaml
+    label: "Trigger workflow_dispatch on a Copilot branch via GitHub CLI (run from local terminal or another workflow)"
+    code: |
+      # Run locally or in a helper workflow step:
+      # gh workflow run deploy.yml --ref copilot/fix-issue-123
+
+      # Or call via the REST API in a workflow step:
+      - name: Dispatch workflow on Copilot branch
+        run: |
+          gh workflow run deploy.yml \
+            --ref "${{ github.head_ref }}" \
+            --repo ${{ github.repository }}
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+prevention:
+  - "Use the GitHub CLI (gh workflow run --ref <branch>) instead of the UI when targeting Copilot branches"
+  - "Use the REST API dispatches endpoint with an explicit ref to trigger workflows on any branch"
+  - "Follow runner#4246 for updates on when UI support for Copilot branches may be added"
+  - "Build automation that runs in workflow_run triggered by the Copilot branch's push event instead of requiring manual dispatch"
+docs:
+  - url: "https://github.com/actions/runner/issues/4246"
+    label: "runner#4246 — Cannot trigger workflows manually targeting a copilot agent branch (Feb 2026, 15 reactions)"
+  - url: "https://cli.github.com/manual/gh_workflow_run"
+    label: "GitHub CLI — gh workflow run (supports --ref for any branch)"
+  - url: "https://docs.github.com/en/rest/actions/workflows?apiVersion=2022-11-28#create-a-workflow-dispatch-event"
+    label: "GitHub REST API — Create a workflow dispatch event (accepts any ref)"
+  - url: "https://docs.github.com/en/copilot/using-github-copilot/using-copilot-coding-agent-in-github"
+    label: "GitHub Docs — Using Copilot coding agent"

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

@@ -0,0 +1,120 @@
+id: runner-environment-246
+title: 'Container `options:` empty string from matrix causes "The template is not valid. Unexpected value''" in runner >= 2.331.0'
+category: runner-environment
+severity: error
+tags:
+  - container
+  - matrix
+  - container-options
+  - runner-regression
+  - template-validation
+  - runner-2331
+patterns:
+  - regex: 'The template is not valid.*Unexpected value'
+    flags: 'i'
+  - regex: 'Unexpected value .{0,5}\.github/workflows'
+    flags: 'i'
+error_messages:
+  - "Error: The template is not valid. .github/workflows/deploy.yml (Line: 42, Col: 15): Unexpected value ''"
+  - "Error: The template is not valid. .github/workflows/ci.yml (Line: 18, Col: 9): Unexpected value ''"
+root_cause: |
+  In runner version 2.331.0, a regression was introduced in template validation for
+  container job `options:` fields. When a workflow uses a matrix to conditionally set
+  container options — so that some matrix combinations have no container options
+  (`options: ''` or `options: ${{ matrix.container_options }}` where the value is
+  unset/empty) — the runner's template evaluator now rejects the empty string with
+  "Unexpected value ''" and marks the job as failed before it even starts.
+
+  Prior to runner 2.331.0, an empty `options:` string was silently accepted and the
+  container job ran without extra Docker options. The 2.331.0 release tightened template
+  validation for the `container.options` field, rejecting any expression that evaluates
+  to an empty string at runtime.
+
+  **Common trigger pattern:**
+  ```yaml
+  strategy:
+    matrix:
+      include:
+        - os: ubuntu
+          container_options: "--memory=2g"
+        - os: alpine
+          # No container_options key — evaluates to empty string
+  jobs:
+    build:
+      container:
+        image: myapp:latest
+        options: ${{ matrix.container_options }}  # empty for alpine row
+  ```
+
+  This pattern worked on runner 2.330.0 but fails on 2.331.0+ with "Unexpected value ''".
+  The issue is tracked in actions/runner#4204 (open, labeled bug, Jan 2026).
+fix: |
+  Add a fallback non-empty value to the options expression using the `||` operator.
+  A single space `' '` is enough to satisfy the validator while having no effect on
+  the container invocation, since Docker ignores empty/whitespace-only option strings.
+
+  Replace:
+    options: ${{ matrix.container_options }}
+
+  With:
+    options: ${{ matrix.container_options || ' ' }}
+
+  Alternatively, restructure the matrix to always provide a defined (non-empty)
+  `container_options` value, using a neutral default like `'--label=placeholder'`
+  for rows that don't need real options. This is more explicit and survives future
+  validator changes.
+fix_code:
+  - language: yaml
+    label: 'Fallback to single space so template validator accepts an empty matrix value'
+    code: |
+      strategy:
+        matrix:
+          include:
+            - name: with-limits
+              container_options: "--memory=2g --cpus=1"
+            - name: no-limits
+              # container_options intentionally absent
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          container:
+            image: myapp:latest
+            # ✅ Use || ' ' to avoid empty-string rejection in runner >= 2.331.0
+            options: ${{ matrix.container_options || ' ' }}
+          steps:
+            - uses: actions/checkout@v4
+            - run: make build
+  - language: yaml
+    label: 'Explicit neutral default in the matrix row avoids the ambiguity entirely'
+    code: |
+      strategy:
+        matrix:
+          include:
+            - name: with-limits
+              container_options: "--memory=2g --cpus=1"
+            - name: no-limits
+              # ✅ Always set a value — Docker ignores a dummy label at no cost
+              container_options: "--label=no-extra-opts"
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          container:
+            image: myapp:latest
+            options: ${{ matrix.container_options }}
+          steps:
+            - uses: actions/checkout@v4
+            - run: make build
+prevention:
+  - 'Never let `container.options` evaluate to an empty string — always provide a neutral fallback with `|| '' ''` or a dummy label'
+  - 'Test matrix workflows with every combination, including rows that skip optional matrix keys like `container_options`'
+  - 'Pin runner version in self-hosted setups to detect regressions before rolling out to all jobs'
+  - 'Track actions/runner#4204 for a permanent fix; apply the `|| '' ''` workaround in the interim'
+docs:
+  - url: 'https://github.com/actions/runner/issues/4204'
+    label: 'actions/runner#4204: "The template is not valid" when container.options is not set in matrix (open, regression in 2.331.0)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-jobs-in-a-container'
+    label: 'GitHub Docs: Running jobs in a container — options field'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idcontaineroptions'
+    label: 'GitHub Docs: jobs.<job_id>.container.options'

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

@@ -0,0 +1,73 @@
+id: runner-environment-247
+title: '`apt-get install` stalls ~75 seconds on ubuntu-24.04 — "Processing triggers for man-db" post-install hook'
+category: runner-environment
+severity: warning
+tags:
+  - ubuntu-24.04
+  - apt-get
+  - man-db
+  - package-install
+  - performance
+  - slow
+patterns:
+  - regex: 'Processing triggers for man-db \('
+    flags: 'i'
+  - regex: 'man-db.*stall|stall.*man-db'
+    flags: 'i'
+error_messages:
+  - "Processing triggers for man-db (2.12.0-4build2) ..."
+  - "Processing triggers for man-db (2.12.0-4build2) ..."
+root_cause: |
+  On ubuntu-24.04 runners, installing any package that triggers the `man-db` post-install
+  hook causes a ~75-second stall during the `apt-get install` step.
+
+  The `man-db` daemon (which indexes manual pages for `man` lookups) has a post-install
+  trigger that runs `mandb` to rebuild the manual page database after packages are
+  installed. On ubuntu-24.04, this database rebuild operation runs synchronously and
+  takes approximately 60-90 seconds, blocking the apt post-install phase.
+
+  Any package that installs manual pages (cmake, make, build-essential, gcc, etc.)
+  triggers this slow hook. Workflows that install multiple packages in a single
+  `apt-get install` step will still only pay the cost once (one rebuild per transaction),
+  but even a single apt install with man pages will stall for over a minute.
+
+  The `man-db` package is installed by default on ubuntu-24.04 runner images. This
+  issue was reported in September 2025 and remains open as of June 2026 (runner#4030).
+fix: |
+  Option 1 — Remove man-db before running apt-get install commands:
+  ```yaml
+  - name: Remove man-db to prevent slow post-install trigger
+    run: sudo apt-get remove --purge -y man-db
+  ```
+  After removing man-db, all subsequent apt installs skip the man page indexing trigger.
+
+  Option 2 — Disable the man-db auto-update file (lighter weight):
+  ```yaml
+  - name: Disable man-db auto-update
+    run: sudo rm -f /var/lib/man-db/auto-update
+  ```
+  This deletes the sentinel file that triggers auto-update, preventing the stall without
+  uninstalling man-db.
+
+  Option 3 — Set DEBIAN_FRONTEND and skip recommended packages (partial mitigation):
+  Some packages still trigger man-db via direct page installation, but combining
+  `--no-install-recommends` reduces the set of affected packages.
+fix_code:
+  - language: yaml
+    label: "Remove man-db before apt-get installs to eliminate the stall"
+    code: |
+      - name: Remove man-db (prevents ~75s stall on ubuntu-24.04)
+        run: sudo apt-get remove --purge -y man-db
+
+      - name: Install dependencies
+        run: sudo apt-get install -y cmake make build-essential
+prevention:
+  - "Remove or disable man-db at the start of jobs that run apt-get install on ubuntu-24.04"
+  - "Use sudo rm -f /var/lib/man-db/auto-update as a lighter-weight alternative to removing the package"
+  - "Combine all apt-get installs into a single command to pay the man-db trigger cost only once"
+  - "Monitor job timing — if an apt step takes 75+ extra seconds on ubuntu-24.04, man-db is the cause"
+docs:
+  - url: "https://github.com/actions/runner/issues/4030"
+    label: "GitHub runner#4030 — man-db trigger severely stalls package installation on ubuntu-24.04"
+  - url: "https://manpages.ubuntu.com/manpages/noble/man8/mandb.8.html"
+    label: "Ubuntu mandb(8) manual — man page database indexer"

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

@@ -0,0 +1,106 @@
+id: runner-environment-248
+title: '`actions/checkout` causes "Duplicate header: Authorization" — git returns 400 on subsequent git operations'
+category: runner-environment
+severity: error
+tags:
+  - checkout
+  - git
+  - authorization
+  - http-extraheader
+  - credentials
+  - 400
+  - duplicate-header
+patterns:
+  - regex: 'Duplicate header.*Authorization|remote.*Duplicate header.*Authorization'
+    flags: 'i'
+  - regex: 'fatal.*unable to access.*The requested URL returned error: 400'
+    flags: 'i'
+  - regex: 'http\.extraheader.*AUTHORIZATION.*duplicate|duplicate.*AUTHORIZATION.*extraheader'
+    flags: 'i'
+error_messages:
+  - "remote: Duplicate header: \"Authorization\""
+  - "fatal: unable to access 'https://github.com/org/repo/': The requested URL returned error: 400"
+  - "Error: The process '/usr/bin/git' failed with exit code 128"
+root_cause: |
+  When `actions/checkout` runs, it configures git credentials by setting an
+  `http.extraheader` entry containing an `AUTHORIZATION: bearer <token>` header.
+  This header is added to git's global or repository-level config so that all
+  subsequent git operations over HTTPS are authenticated.
+
+  The "Duplicate header: Authorization" error occurs when a second Authorization
+  header is injected on top of the one already set by checkout. This can happen in
+  two scenarios:
+
+  1. **Pin to @main or an unstable tag**: Using `actions/checkout@main` (or any
+     edge/pre-release revision) picks up unreleased changes that may change the
+     credential injection mechanism. In some checkout versions, the http.extraheader
+     is written in a way that stacks with git's built-in credential manager, sending
+     two conflicting Authorization headers in the same HTTP request.
+
+  2. **Multiple checkout calls with persist-credentials: true** (the default):
+     The first checkout sets the global http.extraheader. A second checkout step
+     (e.g., checking out a second repository) may add a new header without first
+     removing the existing one, depending on the git version and checkout version.
+
+  GitHub's servers reject HTTP requests with two Authorization headers with HTTP 400,
+  returning "Duplicate header: Authorization" in the response. Git then reports
+  `fatal: unable to access ... The requested URL returned error: 400`.
+
+  The bug was reported in checkout#2299 (Nov 2025, 10 reactions) and checkout#2215
+  (Jul 2025, 8 reactions) and remained open as of June 2026.
+fix: |
+  Option 1 — Pin to a stable released version tag instead of @main:
+  Replace `actions/checkout@main` with a specific release tag (e.g.,
+  `actions/checkout@v4` or `actions/checkout@v4.2.2`). The stable release series
+  has known credential injection behaviour that does not produce duplicate headers.
+
+  Option 2 — Clear http.extraheader between checkout steps:
+  If you must run multiple checkout steps, add a step between them to clear the
+  credential header before the second checkout:
+  ```yaml
+  - name: Clear git credentials before second checkout
+    run: git config --global --unset-all http.extraheader || true
+  ```
+
+  Option 3 — Use token: input only on the checkout that needs it and set
+  persist-credentials: false on checkouts that do not need to push:
+  ```yaml
+  - uses: actions/checkout@v4
+    with:
+      persist-credentials: false
+  ```
+fix_code:
+  - language: yaml
+    label: "Pin to stable checkout version to avoid duplicate header bug"
+    code: |
+      - name: Checkout repository
+        uses: actions/checkout@v4   # Pin to stable tag, NOT @main
+        with:
+          fetch-depth: 0
+
+  - language: yaml
+    label: "Clear git extraheader between multiple checkout steps"
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          repository: org/first-repo
+
+      - name: Clear git credentials
+        run: git config --global --unset-all http.extraheader || true
+
+      - uses: actions/checkout@v4
+        with:
+          repository: org/second-repo
+          path: second-repo
+prevention:
+  - "Never pin actions to @main or mutable tags — always use immutable version tags (e.g., @v4 or @v4.2.2)"
+  - "If using multiple checkout steps, set persist-credentials: false on steps that don't require pushing"
+  - "Check git config --global --list | grep extraheader if unexpected 400 errors occur on git operations"
+  - "Upgrade to the latest stable actions/checkout release when a new version is available"
+docs:
+  - url: "https://github.com/actions/checkout/issues/2299"
+    label: "checkout#2299 — Duplicate header: Authorization (Nov 2025, 10 reactions)"
+  - url: "https://github.com/actions/checkout/issues/2215"
+    label: "checkout#2215 — actions/checkout@v4 fails with Duplicate header: Authorization, 400 (Jul 2025, 8 reactions)"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable"
+    label: "GitHub Actions security hardening — credential best practices"

package/errors/silent-failures/silent-failures-122.yml

@@ -0,0 +1,102 @@
+id: silent-failures-122
+title: '`fetch-tags: false` is silently ignored when `fetch-depth: 0` — all tags are still fetched'
+category: silent-failures
+severity: silent-failure
+tags:
+  - checkout
+  - fetch-tags
+  - fetch-depth
+  - git
+  - tags
+  - shallow-clone
+  - option-conflict
+patterns:
+  - regex: 'fetch-tags.*false.*fetch-depth.*0|fetch-depth.*0.*fetch-tags.*false'
+    flags: 'i'
+  - regex: 'tags.*still.*fetched|fetching.*tags.*despite.*false'
+    flags: 'i'
+error_messages:
+  - "# No error message — tags are silently fetched despite fetch-tags: false"
+root_cause: |
+  `actions/checkout` provides two related but conflicting inputs:
+  - `fetch-depth: 0` — fetches ALL commits and branches (unshallow clone); this
+    implicitly fetches ALL tags as well because full history requires resolving all
+    tag references
+  - `fetch-tags: false` — instructs the action NOT to fetch tags
+
+  When BOTH options are used together (`fetch-depth: 0` and `fetch-tags: false`),
+  `fetch-tags: false` is silently ignored. The full-history fetch that `fetch-depth: 0`
+  triggers uses a git fetch command that includes tag references, and the action does
+  not apply a `--no-tags` flag in this code path.
+
+  As a result, all repository tags end up in the local clone even though the workflow
+  explicitly requested `fetch-tags: false`. There is no error, warning, or annotation
+  — the tags are simply present.
+
+  This is a code-path gap in actions/checkout rather than a documented design decision.
+  The issue was reported in checkout#2195 (Jun 2025, 10 reactions) and remained open
+  as of June 2026.
+
+  Common situations where this matters:
+  - Workflows that use `git describe` and want to avoid picking up pre-release or
+    unrelated tags from the full history
+  - Versioning scripts that filter by tag presence to determine release status
+  - Workflows that check `git tag -l` to decide whether to create a new tag
+fix: |
+  Since `fetch-tags: false` is not honoured with `fetch-depth: 0`, the workaround is
+  to explicitly delete the fetched tags in a step immediately after checkout:
+
+  ```yaml
+  - uses: actions/checkout@v4
+    with:
+      fetch-depth: 0
+      fetch-tags: false  # Has no effect — tags are fetched anyway
+
+  - name: Remove all fetched tags (workaround for fetch-depth:0 + fetch-tags:false bug)
+    run: git tag -d $(git tag -l) || true
+  ```
+
+  Alternatively, if the goal is to avoid tag resolution during git operations, use
+  `--no-tags` in subsequent git fetch calls:
+  ```yaml
+  - run: git fetch --no-tags origin
+  ```
+
+  If the full commit history is needed but not all tags, also consider filtering
+  the specific tags needed using `git fetch origin refs/tags/<specific-tag>:refs/tags/<specific-tag>`
+  after deleting the unwanted ones.
+fix_code:
+  - language: yaml
+    label: "Delete all fetched tags after checkout when fetch-tags: false is needed with full history"
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          fetch-tags: false  # NOTE: currently ignored with fetch-depth: 0
+
+      - name: Delete all tags (workaround — fetch-tags:false ignored with fetch-depth:0)
+        run: |
+          TAGS=$(git tag -l)
+          if [ -n "$TAGS" ]; then
+            git tag -d $TAGS
+          fi
+
+  - language: yaml
+    label: "Fetch full history via explicit git command with --no-tags as an alternative"
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 1  # Shallow initial checkout
+
+      - name: Fetch full history without tags
+        run: git fetch --unshallow --no-tags
+prevention:
+  - "Do not rely on fetch-tags: false to suppress tag fetching when fetch-depth: 0 is also set — it has no effect"
+  - "If tag presence affects workflow logic, explicitly verify the tag state with git tag -l after checkout"
+  - "Track checkout#2195 for a fix in future actions/checkout releases"
+  - "As a workaround, delete all tags after checkout using: git tag -d $(git tag -l) || true"
+docs:
+  - url: "https://github.com/actions/checkout/issues/2195"
+    label: "checkout#2195 — fetch-tags: false still fetches tags if fetch-depth is 0 (Jun 2025, 10 reactions)"
+  - url: "https://github.com/actions/checkout#usage"
+    label: "actions/checkout Usage — fetch-depth and fetch-tags inputs"

package/package.json

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