@htekdev/actions-debugger 1.0.118 → 1.0.120

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

@@ -0,0 +1,99 @@
+id: runner-environment-217
+title: 'ubuntu-26.04 Helm 4 — `helm install --atomic` fails with unknown flag error on Helm 4.0.x–4.1.0'
+category: runner-environment
+severity: error
+tags:
+  - helm
+  - helm-4
+  - ubuntu-26
+  - tool-upgrade
+  - flag-renamed
+  - atomic
+patterns:
+  - regex: 'Error: unknown flag: --atomic'
+    flags: 'i'
+  - regex: 'helm install.*Error.*unknown flag.*atomic'
+    flags: 'i'
+error_messages:
+  - 'Error: unknown flag: --atomic'
+  - 'Error: flag provided but not defined: --atomic'
+root_cause: |
+  ubuntu-26.04 runner images install Helm 4. In Helm 4, the `--atomic` flag was
+  renamed to `--rollback-on-failure`. On `helm upgrade`, the old `--atomic` flag
+  was retained as a deprecated alias that emits a warning. However, on
+  `helm install`, the `--atomic` binding was accidentally omitted in Helm 4.0.0,
+  so `helm install --atomic` fails with `Error: unknown flag: --atomic` on Helm
+  versions 4.0.0 through 4.1.0.
+
+  This was reported in helm/helm#31900 and fixed in Helm 4.1.1 via PR #31901
+  (March 4, 2026), which restored `--atomic` as a deprecated alias on
+  `helm install`. However, workflows that pin specific Helm 4 versions via
+  `azure/setup-helm` at versions 4.0.0–4.1.0, or any ubuntu-26.04 image built
+  before the Helm 4.1.1+ update, will still hit this error.
+
+  `--atomic` is extremely common in Kubernetes deployment workflows because it
+  auto-rolls back failed installs and waits for all pods to be Ready.
+fix: |
+  Replace `--atomic` with `--rollback-on-failure` in your `helm install`
+  command. The semantics are identical: on failure, Helm rolls back (uninstalls)
+  the release and returns a non-zero exit code.
+
+  Note: `--wait` is implicitly enabled when `--rollback-on-failure` is set.
+
+  If you must use `--atomic` (e.g., shared scripts that support both Helm 3 and 4),
+  pin Helm 3 with `azure/setup-helm` or ensure Helm 4.1.1+ is installed.
+fix_code:
+  - language: yaml
+    label: 'Replace --atomic with --rollback-on-failure (Helm 4 syntax)'
+    code: |
+      - name: Deploy chart
+        run: |
+          # Helm 4 on ubuntu-26.04: --atomic is removed from helm install (4.0.x-4.1.0).
+          # Use --rollback-on-failure instead (semantically identical):
+          helm install my-release ./chart \
+            --namespace production \
+            --rollback-on-failure \
+            --timeout 5m0s
+
+  - language: yaml
+    label: 'Pin Helm version to avoid flag compatibility issues'
+    code: |
+      - name: Set up Helm
+        uses: azure/setup-helm@v5
+        with:
+          version: '3.17.x'   # Use Helm 3 if --atomic is required and not yet migrated
+          # Or use Helm 4.1.1+ which restores --atomic as a deprecated alias:
+          # version: '4.1.1'
+
+      - name: Deploy chart
+        run: |
+          helm install my-release ./chart \
+            --namespace production \
+            --atomic \
+            --timeout 5m0s
+
+  - language: yaml
+    label: 'Upgrade and install combined (helm upgrade --install)'
+    code: |
+      - name: Deploy chart
+        run: |
+          # helm upgrade retains --atomic as deprecated in all Helm 4 versions.
+          # Use upgrade --install as an alternative that works across Helm 3 and 4:
+          helm upgrade --install my-release ./chart \
+            --namespace production \
+            --atomic \
+            --timeout 5m0s
+prevention:
+  - "Use `helm upgrade --install` instead of `helm install` when possible — `--atomic` was retained on upgrade in all Helm 4 versions."
+  - "Pin Helm versions with `azure/setup-helm` to avoid silent tool version changes when ubuntu-latest migrates to ubuntu-26.04."
+  - "Replace `--atomic` with `--rollback-on-failure` in new workflows — this is the Helm 4 canonical flag name."
+  - "Run `helm version` as an early step to catch unexpected version jumps before the deployment step."
+docs:
+  - url: 'https://github.com/helm/helm/issues/31900'
+    label: 'helm/helm#31900 — helm install --atomic no longer works in Helm 4'
+  - url: 'https://github.com/helm/helm/pull/31901'
+    label: 'helm/helm#31901 — fix: restore deprecated --atomic flag on install for backwards compatibility'
+  - url: 'https://helm.sh/docs/topics/v4_migration/'
+    label: 'Helm v4 Migration Guide — CLI flag renames'
+  - url: 'https://github.com/actions/runner-images/commit/9e3319d6b4acc306925295853d0ff41ddd5c40f0'
+    label: 'runner-images commit: ubuntu-26.04 installs Helm 4'

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

@@ -0,0 +1,111 @@
+id: runner-environment-218
+title: "docker/build-push-action 'load: true' and 'push: true' Are Mutually Exclusive"
+category: runner-environment
+severity: error
+tags:
+  - docker
+  - build-push-action
+  - buildx
+  - buildkit
+  - load
+  - push
+patterns:
+  - regex: 'load.{0,20}push cannot be both set|cannot use both --load and --push|load.*push.*incompatible|--load.*--push.*incompatible'
+    flags: 'i'
+  - regex: "contradictory options given: load and push"
+    flags: 'i'
+error_messages:
+  - "contradictory options given: load and push cannot be both set at the same time"
+  - "ERROR: cannot use both --load and --push flags"
+  - "error: '--load' and '--push' cannot be used together"
+  - "Error: buildx failed with: error: failed to solve: load and push cannot be both set"
+root_cause: |
+  docker/build-push-action (and the underlying docker buildx) does not support
+  setting both 'load: true' and 'push: true' in the same build step. These two
+  options are mutually exclusive:
+
+  - 'load: true' exports the built image into the local Docker daemon
+    (equivalent to --load / --output type=docker).
+  - 'push: true' pushes the image to a remote registry
+    (equivalent to --push / --output type=registry).
+
+  Both flags specify different output targets, and docker buildx cannot satisfy
+  both simultaneously with most drivers. The docker-container and kubernetes
+  drivers explicitly reject the combination. The docker driver (used without
+  explicit driver setup) may silently ignore 'push' in some versions.
+
+  Common triggers:
+  - Copying a workflow snippet that has 'push: true' and adding 'load: true'
+    for local testing without removing 'push: true'.
+  - Conditional 'push' logic using expressions that evaluate to true at the
+    same time as unconditional 'load: true'.
+fix: |
+  Use only one of 'load' or 'push' in a single step. To both test locally and
+  push to a registry, split the build into two separate steps, or use
+  conditional logic so only one output target is active at a time.
+
+  The idiomatic pattern is:
+  - Set 'push: ${{ github.ref == 'refs/heads/main' }}' to push only on
+    default branch, and omit 'load:' entirely (or use a separate step for
+    local testing).
+  - To load the image for integration tests AND push on main, build twice:
+    once with 'load: true' for tests, once with 'push: true' for release.
+  - Use build outputs caching (cache-from/cache-to) so the second build
+    is fast.
+fix_code:
+  - language: yaml
+    label: "Wrong — load and push both true (fails)"
+    code: |
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          load: true      # ❌ Incompatible with push: true
+          push: true      # ❌ Incompatible with load: true
+          tags: myrepo/myimage:latest
+
+  - language: yaml
+    label: "Fixed — push conditionally, no load"
+    code: |
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: ${{ github.ref == 'refs/heads/main' }}
+          tags: myrepo/myimage:latest
+
+  - language: yaml
+    label: "Fixed — load for tests, push separately on main"
+    code: |
+      - name: Build image for integration tests
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          load: true        # ✅ load only — no push
+          tags: myrepo/myimage:test
+
+      - name: Run integration tests
+        run: docker run --rm myrepo/myimage:test ./run-tests.sh
+
+      - name: Push to registry (main branch only)
+        if: github.ref == 'refs/heads/main'
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true        # ✅ push only — no load
+          tags: myrepo/myimage:latest
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+
+prevention:
+  - "Never set both 'load: true' and 'push: true' in the same build-push-action step."
+  - "Use 'push: ${{ condition }}' expression to conditionally push; omit 'load' in the same step."
+  - "If you need the image locally for testing and also want to push, use two separate steps."
+  - "Review docker/build-push-action README — the compatibility matrix for load, push, and outputs is documented."
+docs:
+  - url: "https://github.com/docker/build-push-action#inputs"
+    label: "docker/build-push-action — inputs reference (load, push, outputs)"
+  - url: "https://docs.docker.com/build/building/export/"
+    label: "Docker Buildx — build output types (load vs push)"
+  - url: "https://github.com/docker/build-push-action/blob/master/README.md#multi-platform-image"
+    label: "docker/build-push-action — multi-platform and output guidance"

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

@@ -0,0 +1,119 @@
+id: silent-failures-109
+title: 'electron-forge make Silently Exits 0 on Node.js 24.16.0+ — No .exe, No Error'
+category: silent-failures
+severity: silent-failure
+tags:
+  - electron-forge
+  - nodejs
+  - node24
+  - extract-zip
+  - toolcache
+  - regression
+  - windows
+  - packaging
+patterns:
+  - regex: 'Invalid input file path.{0,80}\.exe'
+    flags: 'i'
+  - regex: 'Finalizing package\s*$'
+    flags: 'im'
+  - regex: 'electron-forge make.{0,60}exit(?:ed)? (?:with )?(?:code )?0'
+    flags: 'i'
+  - regex: 'exec\: node\: not found'
+    flags: 'i'
+error_messages:
+  - 'Error: Invalid input file path - apps/desktop/out/<AppName>-win32-x64/<App>.exe'
+  - '❯ Finalizing package'
+  - 'exec: node: not found'
+  - '> Packaging for x64 on win32'
+root_cause: |
+  On the ubuntu-24.04 image update from 20260518.149.1 → 20260525.161.1 and
+  the Windows Server 2022/2025 image update from 20260518 → 20260525, the
+  cached Node.js toolcache version was bumped from 24.15.0 to 24.16.0. Node.js
+  24.16.0 contains an upstream regression in the readable-stream.destroy()
+  lifecycle that breaks yauzl (a ZIP reading library) and extract-zip which
+  depends on it.
+
+  `electron-forge make` uses extract-zip internally during the "Finalizing
+  package" phase to extract the Electron binary archive. When running under
+  Node.js 24.16.0 or 26.1.0+, the forge process:
+  1. Enters all packaging subtasks within ~5 ms (each spinner shows up instantly)
+  2. Exits with code 0 — no checkmarks, no error, no output
+  3. Produces no .exe in `out/<AppName>-win32-x64/`
+
+  The same regression affects other tools that use extract-zip internally:
+  - jsvu (JS engine version updater)
+  - Any npm package that has not yet migrated away from the 6-year-old
+    unmaintained extract-zip package
+
+  The affected subtasks (Copying files → Preparing native dependencies →
+  Finalizing package) complete within milliseconds instead of minutes, which
+  is the visible telltale sign — none receive a ✓ checkmark.
+
+  Upstream issues:
+  - https://github.com/nodejs/node/issues/63487 (yauzl/extract-zip partial extraction)
+  - https://github.com/nodejs/node/issues/63638 (libuv regression on Windows)
+  - https://github.com/electron/forge/issues/4277
+fix: |
+  Pin Node.js to 24.15.0 (last unaffected 24.x release) until Node.js 24.17.0
+  ships the upstream fix and it is rolled into the runner toolcache via
+  actions/node-versions:
+
+    - uses: actions/setup-node@v6
+      with:
+        node-version: '24.15.0'
+
+  Alternatively, downgrade to Node.js 22 LTS which is unaffected:
+
+    - uses: actions/setup-node@v6
+      with:
+        node-version: '22'
+
+  For jsvu users, the same pin applies. Track the upstream fix at
+  https://github.com/nodejs/node/issues/63487 and
+  https://github.com/electron/forge/issues/4277 for when to unpin.
+fix_code:
+  - language: yaml
+    label: 'Pin Node.js to 24.15.0 until extract-zip regression is fixed'
+    code: |
+      steps:
+        - uses: actions/checkout@v6
+
+        - name: Set up Node.js (pin to last unaffected 24.x)
+          uses: actions/setup-node@v6
+          with:
+            node-version: '24.15.0'   # 24.16.0+ breaks extract-zip / electron-forge
+            cache: 'npm'
+
+        - name: Install dependencies
+          run: npm ci
+
+        - name: Package (electron-forge)
+          run: npx electron-forge make --platform win32 --arch x64
+  - language: yaml
+    label: 'Fallback to Node.js 22 LTS (unaffected by regression)'
+    code: |
+      steps:
+        - uses: actions/setup-node@v6
+          with:
+            node-version: '22'   # LTS — unaffected by 24.16.0 extract-zip regression
+prevention:
+  - 'Pin exact Node.js minor versions in actions/setup-node — semver ranges like
+    "24" silently upgrade to patch/minor releases that may carry regressions.'
+  - 'Watch https://github.com/nodejs/node/issues/63487 and
+    https://github.com/electron/forge/issues/4277 for when the regression is
+    fixed in both Node.js upstream and electron-forge itself.'
+  - 'If forge make exits 0 but produces no output files, check whether the Node.js
+    version in use is >=24.16.0 or >=26.1.0 — the silent exit is the diagnostic.'
+  - 'Consider using a lock-file approach: pin node-version in setup-node AND add
+    a post-step assertion that the expected .exe exists before continuing.'
+docs:
+  - url: 'https://github.com/nodejs/node/issues/63487'
+    label: 'nodejs/node #63487 — yauzl/extract-zip hang and partial extraction (readable-stream regression)'
+  - url: 'https://github.com/nodejs/node/issues/63638'
+    label: 'nodejs/node #63638 — libuv regression in Node.js 24.16.0 on Windows'
+  - url: 'https://github.com/electron/forge/issues/4277'
+    label: 'electron/forge #4277 — make exits 0 silently on Node.js 24.16.0 / extract-zip regression'
+  - url: 'https://github.com/actions/runner-images/issues/14174'
+    label: 'runner-images #14174 — Windows 2022/2025 May 25 image: electron-forge make silent exit'
+  - url: 'https://github.com/actions/runner-images/issues/14173'
+    label: 'runner-images #14173 — Puppeteer broken in ubuntu-24.04 20260525 (same root cause)'

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

@@ -0,0 +1,91 @@
+id: silent-failures-110
+title: 'setup-node v6 cache:npm silently aborts entire Windows job when npm cache directory does not exist'
+category: silent-failures
+severity: silent-failure
+tags:
+  - setup-node
+  - windows
+  - npm
+  - cache
+  - silent-failure
+  - fresh-runner
+  - npm-cache-path
+patterns:
+  - regex: 'Found in cache.*\n(?:.*\n){0,5}Post job cleanup'
+    flags: 'im'
+  - regex: 'npm config get cache.*\n(?:.*\n){0,3}(?:Detected npm|Auto caching)'
+    flags: 'im'
+  - regex: 'setup-node.*cache.*npm.*windows.*abort'
+    flags: 'i'
+error_messages:
+  - 'Found in cache @ C:\hostedtoolcache\windows\node\22...'
+  - 'Detected npm as the package manager from package.json'
+  - 'Auto caching has been enabled for npm.'
+root_cause: |
+  actions/setup-node@v6 with `cache: 'npm'` (or auto-detected npm caching when
+  package.json has `packageManager: npm`) calls `npm config get cache` to locate the
+  npm cache directory before registering it with actions/cache.
+
+  On fresh Windows runners (hosted or self-hosted), `C:\npm\cache` does not yet exist
+  because no prior npm install has run in this workspace. The Node.js process executing
+  `npm config get cache` internally tries to initialise the npm config directory and
+  hits an EEXIST or missing-parent-directory race in npm's cache initialisation code
+  (npm/cli#7308). The runner process exits after ~24 seconds with no error message and
+  no non-zero exit code.
+
+  The result: every step AFTER setup-node is silently skipped. The job shows as
+  "Success" or the failure appears much later in a confusing step, making this
+  extremely hard to diagnose.
+
+  Affected versions: actions/setup-node@v6.4.0+; most frequently seen on
+  `windows-latest` and `windows-2025` hosted runners.
+fix: |
+  Remove `cache: 'npm'` from setup-node on Windows runners and handle npm caching
+  separately using actions/cache pointing at `~/.npm` or the correct Windows path.
+
+  Alternatively, run a no-op npm command before setup-node to force-create the cache
+  directory (not recommended as a long-term fix).
+
+  If npm caching is needed, use setup-node without `cache:` and add an explicit
+  actions/cache step after npm install has run at least once.
+fix_code:
+  - language: yaml
+    label: 'Remove cache:npm from setup-node; handle caching separately'
+    code: |
+      - uses: actions/setup-node@v6
+        with:
+          node-version: '22'
+          # Do NOT set cache: 'npm' on Windows — it silently aborts on fresh runners
+
+      - name: Get npm cache dir
+        id: npm-cache-dir
+        shell: pwsh
+        run: echo "dir=$(npm config get cache)" >> $env:GITHUB_OUTPUT
+
+      - uses: actions/cache@v4
+        with:
+          path: ${{ steps.npm-cache-dir.outputs.dir }}
+          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+          restore-keys: |
+            ${{ runner.os }}-npm-
+
+      - run: npm ci
+  - language: yaml
+    label: 'Cross-platform: use cache:npm only on non-Windows'
+    code: |
+      - uses: actions/setup-node@v6
+        with:
+          node-version: '22'
+          cache: ${{ runner.os != 'Windows' && 'npm' || '' }}
+prevention:
+  - 'Never set cache: npm in setup-node for Windows-targeted jobs without verifying the npm cache directory pre-exists.'
+  - 'When targeting multiple OSes with a matrix, conditionally disable cache:npm on Windows runners.'
+  - 'After setup-node on Windows, immediately run a trivial npm command (e.g., npm --version) and verify the step succeeds before continuing.'
+  - 'Pin setup-node version and watch the changelog for fixes to the Windows npm cache init race.'
+docs:
+  - url: 'https://github.com/unslothai/unsloth/pull/5474'
+    label: 'unsloth PR #5474 — drop cache:npm from setup-node (silent abort on Windows)'
+  - url: 'https://github.com/npm/cli/issues/7308'
+    label: 'npm/cli#7308 — EEXIST/missing-dir race in npm cache directory initialisation'
+  - url: 'https://github.com/actions/setup-node/issues/1556'
+    label: 'setup-node#1556 — setup-node silently falls through on download/extract failure'

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

@@ -0,0 +1,107 @@
+id: silent-failures-111
+title: '`helm list` shows all release states by default in Helm 4 — scripts silently return unexpected releases'
+category: silent-failures
+severity: silent-failure
+tags:
+  - helm
+  - helm-4
+  - ubuntu-26
+  - tool-upgrade
+  - output-change
+  - deploy-check
+patterns:
+  - regex: 'helm list'
+    flags: 'i'
+error_messages:
+  - '# No error message — helm list exits 0 but returns FAILED/SUPERSEDED/UNINSTALLED releases alongside DEPLOYED ones'
+root_cause: |
+  In Helm 3, `helm list` (without flags) only returned releases in the DEPLOYED
+  state. To see releases in all states, you had to pass `-a`/`--all`.
+
+  In Helm 4 (installed on ubuntu-26.04), `helm list` returns releases of ALL
+  states by default: DEPLOYED, FAILED, SUPERSEDED, UNINSTALLED, PENDING_INSTALL,
+  PENDING_UPGRADE, PENDING_ROLLBACK. The `-a`/`--all` flag was temporarily removed
+  (helm/helm#31784) and restored as a deprecated no-op in Helm 4.1.1+.
+
+  This causes silent failures in two common patterns:
+
+  1. **Existence check**: `helm list --filter my-release | grep my-release` returns
+     a match even if the release is in a FAILED state, causing a subsequent
+     `helm upgrade` to proceed when `helm install` should have been used instead
+     (or vice versa).
+
+  2. **Release count**: Scripts that count `helm list | wc -l` to assert a number
+     of deployed releases now count more releases than expected.
+
+  3. **CI deploy gate**: Pipelines that run `helm list` to verify a deployment
+     succeeded will see FAILED releases included in output and may incorrectly
+     conclude the deployment is present/healthy.
+
+  No error is thrown — `helm list` exits 0 in all cases. The bug is in the
+  consuming script's assumption about Helm 3 behavior.
+fix: |
+  Filter `helm list` output explicitly by state using the `--deployed` flag
+  or the `--filter`+`--output json` approach to check actual release status.
+
+  In Helm 4, use `helm status <release>` to get the definitive state of a
+  specific release rather than parsing `helm list` output.
+fix_code:
+  - language: yaml
+    label: 'Use --deployed flag to replicate Helm 3 default behavior'
+    code: |
+      - name: Check if release is deployed
+        run: |
+          # Helm 4 on ubuntu-26.04: helm list shows ALL states by default.
+          # Use --deployed to replicate Helm 3 default behavior:
+          DEPLOYED=$(helm list --deployed --filter "^my-release$" --short)
+          if [ -n "$DEPLOYED" ]; then
+            echo "Release is deployed — running upgrade"
+            helm upgrade my-release ./chart
+          else
+            echo "No deployed release found — running install"
+            helm install my-release ./chart
+          fi
+
+  - language: yaml
+    label: 'Use helm status for definitive state check'
+    code: |
+      - name: Check release status
+        run: |
+          # helm status exits non-zero if the release does not exist.
+          # Use --output json to get machine-parseable state:
+          STATUS=$(helm status my-release --output json 2>/dev/null | jq -r '.info.status' || echo "not-found")
+          echo "Release status: $STATUS"
+          if [ "$STATUS" = "deployed" ]; then
+            echo "Healthy — proceeding"
+          elif [ "$STATUS" = "failed" ]; then
+            echo "Previous install failed — rolling back before upgrade"
+            helm rollback my-release 0  # Roll back to last successful
+          else
+            echo "Installing fresh"
+            helm install my-release ./chart
+          fi
+
+  - language: yaml
+    label: 'Use helm list --output json for precise state parsing'
+    code: |
+      - name: List only deployed releases
+        run: |
+          # Explicitly request only DEPLOYED state, output JSON for safe parsing:
+          helm list --deployed --output json | jq '.[] | .name + " (" + .status + ")"'
+          # Do NOT rely on: helm list | grep release-name
+          # In Helm 4, this matches FAILED/SUPERSEDED releases too.
+prevention:
+  - "Never use `helm list | grep <release>` as a deployment check — it matches any release state in Helm 4."
+  - "Use `helm list --deployed` or `helm status <release>` for definitive deployed-state checks."
+  - "When migrating to ubuntu-26.04, audit all scripts that parse `helm list` output."
+  - "Add `--output json` to `helm list` calls and parse `status` field explicitly rather than relying on line-presence checks."
+  - "Pin Helm 3 with `azure/setup-helm` if your scripts are not yet Helm 4 compatible."
+docs:
+  - url: 'https://github.com/helm/helm/issues/31784'
+    label: 'helm/helm#31784 — Breaking change to helm list CLI command in v4'
+  - url: 'https://helm.sh/docs/topics/v4_migration/'
+    label: 'Helm v4 Migration Guide'
+  - url: 'https://helm.sh/docs/helm/helm_list/'
+    label: 'helm list command reference'
+  - url: 'https://github.com/actions/runner-images/commit/9e3319d6b4acc306925295853d0ff41ddd5c40f0'
+    label: 'runner-images commit: ubuntu-26.04 installs Helm 4'

package/errors/yaml-syntax/yaml-syntax-072.yml

@@ -0,0 +1,93 @@
+id: yaml-syntax-072
+title: 'concurrency queue: max rejected as "Unknown Property" by act and actionlint (May 2026 schema lag)'
+category: yaml-syntax
+severity: error
+tags:
+  - concurrency
+  - queue
+  - act
+  - actionlint
+  - schema-validation
+  - local-ci
+  - queue-max
+patterns:
+  - regex: 'Unknown Property queue'
+    flags: 'i'
+  - regex: 'Failed to match concurrency-mapping.*Unknown Property queue'
+    flags: 'is'
+  - regex: 'concurrency.*queue.*unknown|queue.*max.*schema.*invalid'
+    flags: 'i'
+  - regex: 'actionlint.*"queue".*unknown key'
+    flags: 'i'
+error_messages:
+  - "Line: 4 Column 3: Unknown Property queue"
+  - "Failed to match concurrency-mapping: Line: 6 Column 3: Unknown Property queue"
+  - 'Actions YAML Schema Validation Error detected: Unknown Property queue'
+  - 'unknown key "queue" for "concurrency"'
+root_cause: |
+  GitHub added the `queue` field to the concurrency block in May 2026 (Changelog:
+  "GitHub Actions concurrency groups now allow larger queues"). The new field accepts
+  `single` (default — one pending run) or `max` (up to 100 queued runs).
+
+  Local workflow tooling has not been updated to recognize this field:
+
+  - **nektos/act ≤0.2.88** — `pkg/schema/workflow_schema.json` defines `concurrency-mapping`
+    with only `group` and `cancel-in-progress`. Any workflow using `queue: max` or
+    `queue: single` fails immediately at schema validation, before any step runs.
+
+  - **rhysd/actionlint ≤1.7.8** — the actionlint parser similarly rejects `queue` as an
+    unknown concurrency key, blocking pre-commit hooks and CI lint gates.
+
+  This is a **tooling lag** — the workflow is perfectly valid on GitHub.com and runs
+  correctly in hosted runners. The failure only occurs in local development environments
+  and CI pipelines that use act or actionlint for pre-flight validation.
+
+  SchemaStore (github-workflow.json) already encodes the `queue` enum, so VS Code's
+  GitHub Actions extension does NOT exhibit this error.
+fix: |
+  Until act and actionlint release updated versions with queue support, use one of:
+
+  1. Upgrade act to a version that includes PR #6097 (queue schema fix) — check
+     github.com/nektos/act for the minimum patched version.
+
+  2. Upgrade actionlint to a version that includes the fix for issue #657.
+
+  3. Skip schema validation for workflows that use queue (act: add --no-schema-valid flag;
+     actionlint: add -ignore 'queue' comment).
+
+  4. Temporarily remove queue: max while waiting for local tooling to catch up; GitHub.com
+     itself already supports it and local validation is the only blocker.
+fix_code:
+  - language: yaml
+    label: 'Correct workflow syntax — valid on GitHub.com even if local tools reject it'
+    code: |
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        cancel-in-progress: false
+        queue: max    # queues up to 100 pending runs instead of cancelling them
+  - language: yaml
+    label: 'Suppress actionlint error with inline ignore comment'
+    code: |
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        cancel-in-progress: false
+        queue: max  # actionlint:ignore
+  - language: yaml
+    label: 'Skip act schema validation flag (temporary workaround)'
+    code: |
+      # In .actrc or CLI:
+      # act --no-schema-validate
+prevention:
+  - 'Pin act and actionlint versions in your tooling and monitor their changelogs when GitHub Actions releases new YAML keys.'
+  - 'When a workflow is valid on GitHub.com but rejected locally, check if it uses a recently-added key (queue, timezone, etc.) that local tools have not caught up with.'
+  - 'Use the SchemaStore github-workflow.json schema in VS Code for real-time validation — it tends to be updated faster than act/actionlint.'
+  - 'Do not block PR merges on local-only actionlint errors when the same workflow runs successfully in GitHub Actions CI.'
+docs:
+  - url: 'https://github.com/nektos/act/issues/6095'
+    label: 'nektos/act#6095 — concurrency.queue fails schema validation (May 2026)'
+  - url: 'https://github.com/rhysd/actionlint/issues/657'
+    label: 'rhysd/actionlint#657 — unknown key "queue" for concurrency'
+  - url: 'https://github.blog/changelog/2026-05-07-github-actions-concurrency-groups-now-allow-larger-queues/'
+    label: 'GitHub Changelog — concurrency groups now allow larger queues (May 2026)'
+  - url: 'https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#concurrencyqueue'
+    label: 'GitHub Docs — concurrency.queue syntax reference'