@htekdev/actions-debugger 1.0.14 → 1.0.16

package/errors/caching-artifacts/setup-ruby-bundler-ephemeral-workdir-cache-miss.yml

@@ -0,0 +1,147 @@
+id: caching-artifacts-018
+title: "setup-ruby Bundler Cache Always Misses on Ephemeral Self-Hosted Runners Due to Workdir in Cache Key"
+category: caching-artifacts
+severity: silent-failure
+tags:
+  - ruby
+  - setup-ruby
+  - bundler
+  - cache
+  - self-hosted
+  - ephemeral
+  - cache-miss
+  - cache-key
+patterns:
+  - regex: "Cache not found for.*setup-ruby-bundler-cache.*wd-.*[0-9]{8,}"
+    flags: "i"
+  - regex: "setup-ruby-bundler-cache.*wd-\\/.*[a-f0-9]{8,}.*Gemfile\\.lock"
+    flags: "i"
+  - regex: "No cache found.*setup-ruby-bundler.*workdir.*ephemeral"
+    flags: "i"
+  - regex: "Cache miss.*bundler.*setup-ruby.*self-hosted"
+    flags: "i"
+error_messages:
+  - "Cache not found for input keys: setup-ruby-bundler-cache-v6-ubuntu-22.04-x64-ruby-3.3.6-wd-/codebuild/output/src1813367680/src/actions-runner/_work/myapp/myapp-with--without--only--Gemfile.lock-3f96ad38..."
+  - "No cache found for key: setup-ruby-bundler-cache-v6-..."
+root_cause: |
+  `ruby/setup-ruby` includes the absolute working directory path (`wd-<path>`) as a
+  component of the Bundler cache key. The full cache key format is:
+
+    setup-ruby-bundler-cache-v{VERSION}-{OS}-{ARCH}-ruby-{RUBY_VERSION}-wd-{WORKDIR}-...{GEMFILE_HASH}
+
+  On GitHub-hosted runners, the working directory is deterministic per run
+  (`/home/runner/work/{repo}/{repo}` on Linux), so the cache key is stable across runs
+  and the cache is reused correctly.
+
+  On **ephemeral self-hosted runners** (e.g., AWS CodeBuild, GitLab CI runners with
+  unique workspace paths, or any runner that generates a unique working directory path
+  per run for isolation), the `wd-` component changes with each run. This makes every
+  cache lookup a miss — the Bundler gems are reinstalled from scratch on every run,
+  completely defeating the purpose of caching.
+
+  This affects:
+  - AWS CodeBuild with GitHub Actions runners (CodeBuild generates unique src paths per build)
+  - Kubernetes-based ephemeral runners where the pod workspace path includes a job ID
+  - Any custom runner setup that includes a timestamp or job ID in the workspace path
+
+  The issue is open (ruby/setup-ruby#904, April 2026) and has no upstream fix yet as of
+  mid-2026. The workdir was included in the cache key to allow multiple Ruby projects to
+  have separate caches within the same repository, but it breaks ephemeral runners as a
+  side effect.
+
+  Note: This is a **silent failure** — no error is thrown; the workflow succeeds but Bundler
+  installs all gems on every run, causing slow CI with no visible warning about cache
+  effectiveness.
+fix: |
+  **Workaround 1 — Disable setup-ruby's built-in bundler cache, use actions/cache manually**:
+  Set `bundler-cache: false` in setup-ruby and manage the Bundler cache yourself with
+  `actions/cache`, using only the `BUNDLE_PATH` and `Gemfile.lock` hash as the key
+  (no workdir component). This is the most reliable fix for ephemeral runners.
+
+  **Workaround 2 — Normalize the working directory** (if your runner supports it):
+  Configure your runner to use a fixed, predictable working directory path instead of
+  a unique-per-job path. This makes the setup-ruby cache key stable.
+
+  **Workaround 3 — Cache the Ruby gems directory directly**:
+  Cache `~/.bundle` or the Bundler install path rather than the per-project `vendor/bundle`,
+  since the home directory path is typically stable even on ephemeral runners.
+fix_code:
+  - language: yaml
+    label: "Disable setup-ruby cache and use actions/cache with stable key"
+    code: |
+      jobs:
+        test:
+          runs-on: self-hosted   # ephemeral runner
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: ruby/setup-ruby@v1
+              with:
+                ruby-version: '3.3'
+                bundler-cache: false   # Disable built-in cache (broken on ephemeral runners)
+
+            # Cache gems using a workdir-independent key
+            - uses: actions/cache@v4
+              id: bundle-cache
+              with:
+                path: ~/.bundle/cache
+                key: ${{ runner.os }}-bundle-${{ hashFiles('**/Gemfile.lock') }}
+                restore-keys: |
+                  ${{ runner.os }}-bundle-
+
+            - name: Install gems
+              run: bundle install --path ~/.bundle/cache
+              if: steps.bundle-cache.outputs.cache-hit != 'true'
+
+            - name: Bundle check
+              run: bundle check || bundle install
+  - language: yaml
+    label: "Cache vendor/bundle with BUNDLE_PATH and stable key (no workdir)"
+    code: |
+      jobs:
+        test:
+          runs-on: self-hosted
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: ruby/setup-ruby@v1
+              with:
+                ruby-version: '3.3'
+                bundler-cache: false
+
+            - uses: actions/cache@v4
+              with:
+                path: vendor/bundle
+                key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
+                restore-keys: |
+                  ${{ runner.os }}-gems-
+
+            - name: Install gems
+              run: |
+                bundle config path vendor/bundle
+                bundle install --jobs 4 --retry 3
+  - language: yaml
+    label: "GitHub-hosted runner — built-in cache works fine (no workaround needed)"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest   # GitHub-hosted: stable workdir, cache works
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: ruby/setup-ruby@v1
+              with:
+                ruby-version: '3.3'
+                bundler-cache: true   # Works correctly on GitHub-hosted runners
+prevention:
+  - "Always use `bundler-cache: false` with `ruby/setup-ruby` on ephemeral self-hosted runners (CodeBuild, ephemeral Kubernetes runners) and manage caching manually."
+  - "Verify cache effectiveness by checking the `cache-hit` output and monitoring job duration across runs — a stable cache hit means no Bundler reinstall."
+  - "Use workdir-independent cache keys: `${{ runner.os }}-bundle-${{ hashFiles('**/Gemfile.lock') }}` instead of paths that include dynamic segments."
+  - "Track ruby/setup-ruby#904 for an upstream fix that makes the cache key workdir-independent by default."
+docs:
+  - url: "https://github.com/ruby/setup-ruby/issues/904"
+    label: "ruby/setup-ruby#904: Bundler cache not working due to ephemeral workdir (open)"
+  - url: "https://github.com/ruby/setup-ruby#caching-bundle-install-automatically"
+    label: "setup-ruby README: Caching bundle install automatically"
+  - url: "https://github.com/actions/cache/blob/main/README.md"
+    label: "actions/cache README: manual caching approach"

package/errors/caching-artifacts/upload-artifact-v3-retirement-blocked.yml

@@ -0,0 +1,123 @@
+id: caching-artifacts-016
+title: "actions/upload-artifact v3 Automatically Blocked After January 2025 Retirement"
+category: caching-artifacts
+severity: error
+tags:
+  - upload-artifact
+  - download-artifact
+  - v3
+  - deprecated
+  - retirement
+  - brownout
+patterns:
+  - regex: "automatically failed.*deprecated.*version.*upload-artifact"
+    flags: "i"
+  - regex: "This request has been automatically failed because it uses a deprecated version"
+    flags: "i"
+  - regex: "upload-artifact.*v3.*deprecated"
+    flags: "i"
+  - regex: "download-artifact.*v3.*deprecated"
+    flags: "i"
+error_messages:
+  - "This request has been automatically failed because it uses a deprecated version of actions/upload-artifact: v3"
+  - "This request has been automatically failed because it uses a deprecated version of actions/download-artifact: v3"
+root_cause: |
+  GitHub retired **actions/upload-artifact@v3** and **actions/download-artifact@v3**
+  on January 30, 2025. After the retirement date, any workflow still calling v3 of
+  these actions receives an immediate hard failure at the step level — the action
+  does not run; instead, the runner returns:
+
+    "This request has been automatically failed because it uses a deprecated
+     version of actions/upload-artifact: v3"
+
+  **Timeline:**
+  - April 16, 2024 — GitHub announced v3 deprecation and scheduled retirement
+  - November 2024 → January 2025 — Brownout periods (random scheduled failures)
+  - January 30, 2025 — Full retirement: all v3 calls blocked unconditionally
+
+  **Why repos are still affected:**
+  - Many CI configurations were written before the deprecation announcement and
+    were never updated
+  - Reusable workflows called from other orgs/repos may reference v3 internally
+  - Third-party action marketplace actions that internally use v3 as a dependency
+    were broken until their own maintainers upgraded
+  - Workflows with infrequent trigger schedules (e.g., monthly releases) only hit
+    the brownout windows occasionally, masking the problem until full retirement
+
+  Source: GitHub Changelog 2024-04-16, community discussions/149325
+fix: |
+  Upgrade both upload and download steps to v4 simultaneously. Do NOT mix v3 and v4
+  in the same workflow — they use different artifact backends and are not cross-compatible.
+
+  **Key v4 behavior changes to be aware of:**
+  - Artifact names must be unique per workflow run (v4 does NOT overwrite; throws 409)
+  - Hidden files (dotfiles) are excluded by default — set `include-hidden-files: true`
+    if you need them
+  - Cross-repo artifact access requires explicit permissions
+  - GHES instances older than 3.15 do not support v4 — pin to v3 only if on old GHES
+    (but old GHES has its own known issues)
+fix_code:
+  - language: yaml
+    label: "Migrate upload and download to v4 (minimal change)"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: npm run build
+
+            # ❌ Retired — will auto-fail after Jan 30, 2025
+            # - uses: actions/upload-artifact@v3
+            #   with:
+            #     name: dist
+            #     path: dist/
+
+            # ✅ Use v4
+            - uses: actions/upload-artifact@v4
+              with:
+                name: dist
+                path: dist/
+
+        deploy:
+          needs: build
+          runs-on: ubuntu-latest
+          steps:
+            # ✅ Download also on v4 — must match upload version
+            - uses: actions/download-artifact@v4
+              with:
+                name: dist
+                path: dist/
+  - language: yaml
+    label: "Handle v4 duplicate-name conflict if multiple jobs upload the same name"
+    code: |
+      jobs:
+        build:
+          strategy:
+            matrix:
+              target: [linux, windows, macos]
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Build ${{ matrix.target }}" > output.txt
+
+            # v4: artifact names must be unique per run
+            - uses: actions/upload-artifact@v4
+              with:
+                # Append matrix value to keep names unique
+                name: output-${{ matrix.target }}
+                path: output.txt
+prevention:
+  - "Run `grep -r 'upload-artifact@v3\\|download-artifact@v3' .github/` periodically to catch stale version pins."
+  - "Use Dependabot or Renovate to automatically open PRs when GitHub-maintained actions release new major versions."
+  - "Subscribe to the GitHub Changelog (https://github.blog/changelog/) for deprecation notices."
+  - "When upgrading to v4, test artifact names for uniqueness — v4 throws HTTP 409 when the same name is uploaded twice in one run."
+  - "Set `retention-days` explicitly on v4 artifacts; default retention changed between v3 and v4."
+docs:
+  - url: "https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions"
+    label: "GitHub Changelog: Deprecation notice — v3 of the artifact actions"
+  - url: "https://github.com/orgs/community/discussions/149325"
+    label: "Community discussion — workflows failing after artifact v3 retirement"
+  - url: "https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md"
+    label: "actions/upload-artifact — v3 to v4 migration guide"
+  - url: "https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts"
+    label: "GitHub Docs: Storing workflow data as artifacts"

package/errors/caching-artifacts/upload-artifact-v4-large-file-macos-hang.yml

@@ -0,0 +1,111 @@
+id: caching-artifacts-021
+title: "upload-artifact v4 Silently Hangs on Large Files (500MB+) on macOS Runners"
+category: caching-artifacts
+severity: silent-failure
+tags:
+  - upload-artifact
+  - macos
+  - large-file
+  - hang
+  - timeout
+  - silent-failure
+  - v4
+patterns:
+  - regex: "Uploaded bytes \\d+"
+    flags: "i"
+  - regex: "upload-artifact.*stall|stall.*upload-artifact"
+    flags: "i"
+  - regex: "The operation was cancelled.*upload|upload.*operation was cancelled"
+    flags: "i"
+  - regex: "Error: The process.*took too long.*upload-artifact"
+    flags: "i"
+error_messages:
+  - "Uploaded bytes 8388608"
+  - "The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled."
+root_cause: |
+  `actions/upload-artifact@v4` intermittently stalls during upload on macOS GitHub-hosted
+  runners (macos-13-xl-arm64, macos-14-xlarge, macos-15) when artifact size is approximately
+  500 MB or larger. The stall manifests as the upload progress halting after logging "Uploaded
+  bytes XXXXXXXXX" with no further output — the job then exceeds its timeout and is cancelled
+  by GitHub without an explicit error message.
+
+  This behavior was reported and tracked in actions/upload-artifact#527. The hang appears
+  intermittent (roughly 30–50% failure rate for affected workflows), which makes it difficult
+  to diagnose in standard CI logs — the workflow shows as "cancelled" rather than "failed",
+  masking the root cause.
+
+  Contributing factors observed in community reports:
+  - Large uncompressed artifacts (binaries, build artifacts, test reports with raw data)
+  - macOS ARM64 hosted runners appear more susceptible than Linux or Windows runners
+  - Compression level settings do not consistently prevent the hang
+
+  This is a silent failure because:
+  1. The upload simply stops with no error log entry
+  2. The job shows as "cancelled" (not "failed") in the GitHub UI
+  3. Downstream artifact-download steps fail with "no artifact found" — the real cause is upstream
+fix: |
+  Use one or more of these mitigations while the issue is tracked by the actions team:
+
+  1. **Split large artifacts**: Break large upload paths into multiple smaller upload steps, each
+     under ~200MB. This reduces the risk of hitting the hang threshold.
+
+  2. **Add an explicit timeout**: Set `timeout-minutes` on the upload step to detect hangs faster
+     and fail with a clear error rather than waiting for the job-level timeout.
+
+  3. **Retry the upload**: Wrap the upload step in a retry loop or use a community action like
+     `nick-fields/retry` to automatically re-attempt on failure.
+
+  4. **Use direct storage for very large artifacts**: For artifacts over 1GB, upload directly to
+     S3, Azure Blob Storage, or GCS using provider CLI tools. Use upload-artifact only for test
+     reports and smaller build outputs.
+
+  5. **Switch to Linux runners**: If macOS-specific features are not required for the upload
+     phase, run artifact collection on an ubuntu-latest runner where the hang does not occur.
+fix_code:
+  - language: yaml
+    label: "Add timeout and retry to upload step"
+    code: |
+      - name: Upload large artifact
+        uses: actions/upload-artifact@v4
+        timeout-minutes: 10   # fail fast instead of waiting for job timeout
+        with:
+          name: release-binaries
+          path: dist/
+          compression-level: 6
+          retention-days: 7
+  - language: yaml
+    label: "Split large artifact into parts to reduce hang risk"
+    code: |
+      - name: Upload binaries (part 1)
+        uses: actions/upload-artifact@v4
+        with:
+          name: binaries-part1
+          path: dist/platform-a/
+
+      - name: Upload binaries (part 2)
+        uses: actions/upload-artifact@v4
+        with:
+          name: binaries-part2
+          path: dist/platform-b/
+  - language: yaml
+    label: "Upload to S3 for very large artifacts (bypass upload-artifact)"
+    code: |
+      - name: Upload large artifact to S3
+        env:
+          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+        run: |
+          aws s3 cp dist/release.tar.gz s3://my-bucket/artifacts/${{ github.sha }}/release.tar.gz
+          echo "Uploaded to s3://my-bucket/artifacts/${{ github.sha }}/release.tar.gz"
+prevention:
+  - "Keep individual artifact uploads under 200MB per upload step on macOS runners to avoid the hang threshold."
+  - "Always set `timeout-minutes` on upload steps for large files so the CI job fails fast with a clear error instead of silently timing out."
+  - "Monitor for `cancelled` status on jobs that use upload-artifact on macOS — these may be silently failing uploads."
+  - "For release artifacts exceeding 1GB, use cloud storage (S3, Azure Blob, GCS) directly rather than upload-artifact."
+docs:
+  - url: "https://github.com/actions/upload-artifact/issues/527"
+    label: "actions/upload-artifact#527 — macOS large-file upload hang report and discussion"
+  - url: "https://github.com/actions/upload-artifact"
+    label: "actions/upload-artifact — official repository and documentation"
+  - 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/concurrency-timing/always-cleanup-5min-forced-kill.yml

@@ -0,0 +1,140 @@
+id: concurrency-timing-011
+title: "always() Cleanup Jobs Forcibly Killed After 5-Minute Cancellation Timeout"
+category: concurrency-timing
+severity: warning
+tags:
+  - always
+  - cancellation
+  - cleanup
+  - forced-termination
+  - notification
+  - timeout
+  - teardown
+patterns:
+  - regex: "The runner has received a shutdown signal"
+    flags: "i"
+  - regex: "Job was cancelled"
+    flags: "i"
+  - regex: "The operation was canceled"
+    flags: "i"
+error_messages:
+  - "The runner has received a shutdown signal. This can happen when the runner service is stopped, a new job is started, or the runner is in the process of shutting down."
+  - "Job was cancelled"
+root_cause: |
+  When a workflow run is cancelled (manually or via `cancel-in-progress`), GitHub Actions
+  re-evaluates the `if:` condition for every currently running job. Jobs marked with
+  `if: always()` continue running — this is the intended mechanism for cleanup, notifications,
+  and teardown steps.
+
+  However, GitHub enforces a **5-minute hard termination window** after cancellation is
+  initiated. Once 5 minutes have elapsed since the cancellation signal, ALL remaining jobs
+  are forcibly killed by the server, regardless of their `if:` conditions — including jobs
+  explicitly marked `if: always()`.
+
+  This means:
+  - Cleanup jobs that take more than 5 minutes (Terraform destroy, test result uploads,
+    Slack notifications with retries, database teardown) will be killed mid-execution.
+  - The job may appear partially completed in the logs with no clear failure message —
+    it simply stops, often leaving infrastructure in a partial or inconsistent state.
+  - Developers are surprised that `always()` does not guarantee the job completes after
+    a workflow cancellation.
+
+  Common failure scenarios:
+  - Artifact upload in an `if: always()` post-job step when the upload is slow
+  - Terraform `destroy` as a cleanup job when a long-running deployment is cancelled
+  - Notification jobs that retry on transient failures and consume more time than expected
+  - Integration test teardown (database resets, container removal) that exceeds 5 minutes
+
+  Source: GitHub Docs — Canceling a workflow: "After the 5 minute cancellation timeout
+  period, the server will forcibly terminate all jobs that are still running."
+fix: |
+  Design `always()` cleanup jobs to complete well within 5 minutes. Add a job-level
+  `timeout-minutes: 4` to any cleanup job that runs after cancellation so it fails
+  cleanly rather than being force-killed at an unpredictable point.
+
+  For teardown that cannot be shortened, trigger cleanup from a separate workflow using
+  `workflow_run: [completed]` — it runs after the cancelled run fully settles and is
+  not subject to the 5-minute window.
+
+  Use the `cancelled()` expression to detect cancellation and take a fast code path.
+fix_code:
+  - language: yaml
+    label: "Guard cleanup job with timeout-minutes to fail fast before forced kill"
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          timeout-minutes: 60
+          steps:
+            - uses: actions/checkout@v4
+            - run: ./deploy.sh
+
+        cleanup:
+          needs: deploy
+          if: always()
+          runs-on: ubuntu-latest
+          timeout-minutes: 4   # Stay under the 5-min forced-kill window
+          steps:
+            - name: Teardown infrastructure
+              run: ./teardown.sh
+              timeout-minutes: 3   # Per-step guard too
+
+  - language: yaml
+    label: "Use cancelled() to take a fast notification path on cancellation"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - run: ./slow-build.sh
+
+        notify:
+          needs: build
+          if: always()
+          runs-on: ubuntu-latest
+          steps:
+            - name: Quick notification (cancellation — must be fast)
+              if: cancelled()
+              run: |
+                curl -s -X POST "$SLACK_WEBHOOK" \
+                  -H 'Content-type: application/json' \
+                  -d '{"text":"⚠️ Workflow cancelled — cleanup may be incomplete"}'
+
+            - name: Full notification (success or failure path — has time)
+              if: "!cancelled()"
+              run: ./full-notify.sh "${{ needs.build.result }}"
+
+  - language: yaml
+    label: "Post-cancellation teardown via workflow_run — not subject to 5-min window"
+    code: |
+      # cleanup.yml — separate workflow triggered after any completion including cancellation
+      on:
+        workflow_run:
+          workflows: ["Deploy"]
+          types: [completed]
+
+      jobs:
+        teardown:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Emergency cleanup when deploy was cancelled
+              if: github.event.workflow_run.conclusion == 'cancelled'
+              run: ./emergency-teardown.sh
+
+            - name: Normal cleanup on success or failure
+              if: github.event.workflow_run.conclusion != 'cancelled'
+              run: ./standard-teardown.sh
+prevention:
+  - "Keep `if: always()` cleanup jobs under 4 minutes — add `timeout-minutes: 4` as a safety guard."
+  - "Use `if: cancelled()` to detect cancellation and take a fast code path rather than the full teardown path."
+  - "For cleanup that takes longer than 5 minutes, use a separate `workflow_run: [completed]` workflow that runs outside the cancellation window."
+  - "Test cancellation behavior by manually cancelling a long-running workflow and verifying cleanup jobs complete before 5 minutes."
+docs:
+  - url: "https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow"
+    label: "GitHub Docs: Canceling a workflow (5-minute forced termination)"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#status-check-functions"
+    label: "Status check functions: always(), cancelled()"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run"
+    label: "workflow_run event — trigger cleanup after completed workflows"

package/errors/concurrency-timing/concurrency-group-env-context-undefined.yml

@@ -0,0 +1,99 @@
+id: concurrency-timing-010
+title: "env Context Unavailable in Concurrency Group Expression Collapses All Runs"
+category: concurrency-timing
+severity: silent-failure
+tags:
+  - concurrency
+  - env-context
+  - expression
+  - silent-failure
+  - group-collision
+patterns:
+  - regex: "Canceling since a higher priority waiting"
+    flags: "i"
+  - regex: "concurrency.*group.*\"\""
+    flags: "i"
+error_messages:
+  - "Canceling since a higher priority waiting request for '' exists"
+  - "Canceling since a higher priority waiting run was found for ''"
+root_cause: |
+  The `concurrency.group` expression is evaluated at workflow scheduling time, before
+  most runtime contexts are available. The `env` context is one of the contexts that
+  is NOT available when concurrency expressions are evaluated.
+
+  When you use `${{ env.MY_VAR }}` in a concurrency group key:
+  - The expression silently evaluates to an empty string `""`
+  - Every workflow run (across all branches, all events) shares the same group: `""`
+  - Runs from completely unrelated branches cancel each other unexpectedly
+  - The runner may emit "Canceling since a higher priority waiting request for '' exists"
+    with an empty group name — which is the giveaway
+
+  Contexts available in `concurrency.group`: `github`, `inputs`, `vars`
+  Contexts NOT available: `env`, `steps`, `job`, `runner`, `secrets`, `matrix`, `needs`
+
+  This is a documented limitation but easy to miss because the expression evaluates
+  silently without error — it just returns empty string.
+
+  Sources: GitHub Community #26308, #45734, #69704
+fix: |
+  Replace `env` context references in concurrency group expressions with supported
+  contexts. Use `github` (event properties, ref, workflow name), `inputs` (for
+  workflow_dispatch or workflow_call), or `vars` (repository/org variables).
+
+  For environment-specific group keys, use `github.event_name`, `github.ref_name`,
+  `github.workflow`, or pass an explicit input to workflow_dispatch.
+fix_code:
+  - language: yaml
+    label: "Broken — env context evaluates to empty string in concurrency group"
+    code: |
+      # ❌ BROKEN: ${{ env.ENVIRONMENT }} returns "" at scheduling time
+      env:
+        ENVIRONMENT: production
+
+      concurrency:
+        group: deploy-${{ env.ENVIRONMENT }}  # Always evaluates to "deploy-"
+        cancel-in-progress: false
+  - language: yaml
+    label: "Fixed — use github context or vars instead of env"
+    code: |
+      # ✅ FIXED: use github context properties (available at scheduling time)
+      concurrency:
+        group: deploy-${{ github.ref_name }}-${{ github.workflow }}
+        cancel-in-progress: false
+  - language: yaml
+    label: "Fixed — pass environment as workflow_dispatch input for dynamic group key"
+    code: |
+      # ✅ FIXED: expose the value as an input so it's available via `inputs` context
+      on:
+        workflow_dispatch:
+          inputs:
+            environment:
+              required: true
+              type: choice
+              options: [production, staging]
+
+      concurrency:
+        group: deploy-${{ inputs.environment }}
+        cancel-in-progress: false
+  - language: yaml
+    label: "Fixed — use repository variable (vars context is available)"
+    code: |
+      # ✅ FIXED: vars context is available in concurrency expressions
+      concurrency:
+        group: deploy-${{ vars.DEPLOY_ENV }}-${{ github.ref_name }}
+        cancel-in-progress: false
+prevention:
+  - "Only use `github`, `inputs`, and `vars` contexts in `concurrency.group` expressions."
+  - "If you see runs from unrelated branches cancelling each other, inspect the concurrency group key for empty-string evaluation."
+  - "Test concurrency group expressions by adding a step that echoes the group key: `run: echo 'group=${{ github.workflow }}-${{ github.ref_name }}'`."
+  - "If concurrency cancellation messages show an empty group name `''`, the expression evaluated to an empty string."
+  - "Use `vars` (repository/org variables) rather than `env` when you need a configured value in the group key."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-concurrency"
+    label: "Using concurrency — supported expression contexts"
+  - url: "https://github.com/orgs/community/discussions/26308"
+    label: "GitHub Community #26308 — env context not available in concurrency"
+  - url: "https://github.com/orgs/community/discussions/69704"
+    label: "GitHub Community #69704 — concurrency group context limitations"
+  - url: "https://github.com/orgs/community/discussions/45734"
+    label: "GitHub Community #45734 — concurrency expression supported contexts"