@htekdev/actions-debugger 1.0.23 → 1.0.24

package/errors/concurrency-timing/deployment-review-timeout-expired.yml

@@ -0,0 +1,88 @@
+id: "concurrency-timing-021"
+title: "Deployment job expires when environment review timeout lapses"
+category: "concurrency-timing"
+severity: "error"
+tags:
+  - "deployment"
+  - "environment"
+  - "protection-rule"
+  - "review-timeout"
+  - "pending"
+  - "expired"
+patterns:
+  - regex: "was not approved before the review period expired"
+    flags: "i"
+  - regex: "deployment.*review period expired"
+    flags: "i"
+  - regex: "Your deployment to .+ expired"
+    flags: "i"
+error_messages:
+  - "Your deployment to [environment] was not approved before the review period expired."
+root_cause: |
+  Environment protection rules that require manual reviewers have a configurable review
+  timeout (default 30 days; configurable from 1 to 30 days). When a workflow job waits
+  for approval and no reviewer acts within that window, the deployment job automatically
+  fails with a timeout error.
+
+  This creates a silent cascade: while the job is pending, it appears as "Waiting" in
+  the UI with no failure indicator. Needs-dependent jobs that run after the deployment
+  also remain queued. When the timeout fires, the deployment job fails, which then
+  cascade-fails all downstream jobs simultaneously — a large batch of failures with a
+  confusing single root cause.
+
+  Common triggers:
+  - Teams shorten the timeout from 30 days to 1-7 days for security compliance.
+  - Approvers are on leave or in different time zones and miss the notification.
+  - A deployment is triggered late Friday; nobody approves over the weekend.
+  - The notification email was caught by spam filters or notification fatigue.
+fix: |
+  1. Re-run the failed workflow — a fresh run starts a new review clock.
+  2. Increase the review timeout in: repo Settings → Environments → [env]
+     → Protection rules → Required reviewers → "Timeout".
+  3. Add more reviewers or a team with guaranteed availability across time zones.
+  4. Send a proactive notification (Slack, Teams, PagerDuty) at deploy-queue time
+     so reviewers don't have to poll GitHub.
+fix_code:
+  - language: yaml
+    label: "Notify reviewers immediately when the deployment enters the queue"
+    code: |
+      jobs:
+        notify-pending:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Notify reviewers that approval is needed
+              uses: slackapi/slack-github-action@v2
+              with:
+                webhook: ${{ secrets.SLACK_WEBHOOK_URL }}
+                webhook-type: incoming-webhook
+                payload: |
+                  {
+                    "text": ":rocket: Deployment to *production* is waiting for review.\n<${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|Approve here>"
+                  }
+
+        deploy:
+          needs: notify-pending
+          runs-on: ubuntu-latest
+          environment: production
+          steps:
+            - name: Deploy
+              run: ./deploy.sh
+
+  - language: yaml
+    label: "Programmatic re-trigger via workflow_dispatch on expiry (escape hatch)"
+    code: |
+      # After a timeout expiry, re-run the failed workflow via GitHub CLI:
+      # gh run rerun <run-id> --repo owner/repo --failed
+      # Or push a no-op commit to trigger a fresh run.
+prevention:
+  - "Configure Slack/Teams/email notifications that fire when a deployment enters the pending approval state — do not rely on reviewers proactively checking GitHub."
+  - "Add multiple reviewers or use a team as reviewer so a single person's absence doesn't block the pipeline."
+  - "Do not shorten the review timeout below what your team can realistically respond to (e.g., account for weekends and holidays)."
+  - "Use the wait-timer setting only if you need a minimum delay; set it lower than the review timeout."
+docs:
+  - url: "https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments"
+    label: "GitHub Docs — Reviewing deployments"
+  - url: "https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers"
+    label: "GitHub Docs — Environment protection rules: required reviewers and timeout"
+  - url: "https://github.com/orgs/community/discussions/72259"
+    label: "GitHub Community #72259 — Approving environment deployment in Actions"

package/errors/concurrency-timing/job-concurrency-scope-per-run-not-global.yml

@@ -0,0 +1,81 @@
+id: concurrency-timing-016
+title: "Job-Level Concurrency Does Not Prevent Parallel Runs Across Different Workflow Runs"
+category: concurrency-timing
+severity: silent-failure
+tags:
+  - concurrency
+  - job-level
+  - cross-run
+  - mutex
+  - deployment
+patterns:
+  - regex: 'jobs\.[a-zA-Z_-]+\.concurrency'
+    flags: "i"
+  - regex: 'concurrency:\s*\n\s+group:'
+    flags: "im"
+error_messages:
+  - "Multiple deployments running simultaneously"
+  - "Concurrent job executions detected"
+root_cause: |
+  When the `concurrency:` block is placed at the job level (`jobs.<job_id>.concurrency`)
+  rather than the workflow level, the concurrency group is scoped to a single workflow
+  run. This means:
+  - Within one run: duplicate jobs queue against each other (per-run serialization).
+  - Across different runs: jobs with identical concurrency keys execute in parallel with
+    no queuing or cancellation.
+
+  Developers expecting a global mutex — for example, preventing two simultaneous
+  deployments triggered by separate PRs — are surprised when both deploys run
+  concurrently. The GitHub Docs note explicitly states: "If concurrency is specified
+  at a job level, the concurrency group is scoped to that job within the workflow run."
+
+  This is especially confusing because the workflow-level concurrency block syntax is
+  nearly identical to the job-level one, so copy-paste errors are common.
+fix: |
+  Move the concurrency block from the job level to the workflow level (top of the
+  workflow file, alongside `on:` and `name:`). Workflow-level concurrency provides
+  cross-run serialization and prevents parallel executions across all workflow runs.
+
+  For deployment workflows, use cancel-in-progress: false to queue rather than cancel
+  in-flight deployments, preventing accidental skips of intermediate releases.
+fix_code:
+  - language: yaml
+    label: "Wrong: job-level concurrency (only per-run, not cross-run)"
+    code: |
+      # DO NOT USE for cross-run mutex — this only queues within one run
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          concurrency:
+            group: deploy-${{ github.ref }}
+            cancel-in-progress: true
+          steps:
+            - run: ./deploy.sh
+  - language: yaml
+    label: "Correct: workflow-level concurrency (true cross-run mutex)"
+    code: |
+      name: Deploy
+      on: push
+
+      # Workflow-level: prevents parallel deploys across ALL simultaneous runs
+      concurrency:
+        group: deploy-${{ github.ref }}
+        cancel-in-progress: false  # queue deploys, don't skip intermediate releases
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: ./deploy.sh
+prevention:
+  - "Always use workflow-level concurrency when the goal is preventing simultaneous deployments across PRs or pushes."
+  - "Use job-level concurrency only for intra-run fan-out limiting — document intent with a comment."
+  - "Verify cross-run mutex behavior by triggering two simultaneous push runs and checking the Actions tab."
+  - "Prefer cancel-in-progress: false for deploy workflows to avoid skipping intermediate releases."
+  - "Search your workflows for `jobs.<name>.concurrency` and audit whether cross-run isolation is the intent."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-concurrency"
+    label: "GitHub Docs: Controlling concurrency"
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#concurrency"
+    label: "Workflow syntax: concurrency"

package/errors/concurrency-timing/merge-queue-concurrency-cancel-blocks-all.yml

@@ -0,0 +1,86 @@
+id: concurrency-timing-017
+title: "merge_group Trigger With cancel-in-progress Cascades Cancellations Across Queued Merges"
+category: concurrency-timing
+severity: error
+tags:
+  - merge-queue
+  - merge_group
+  - concurrency
+  - cancel-in-progress
+  - branch-protection
+patterns:
+  - regex: "merge_group"
+    flags: "i"
+  - regex: 'cancel-in-progress:\s*true'
+    flags: "i"
+error_messages:
+  - "Some checks were not successful"
+  - "This check was cancelled"
+  - "Run was cancelled by a newer queued run"
+root_cause: |
+  GitHub's merge queue processes PRs by grouping them and running CI on each queued
+  batch via the `merge_group` event. When a workflow triggered by `merge_group` uses a
+  shared concurrency group key with `cancel-in-progress: true`, each new PR entry in
+  the queue triggers a new workflow run. Because the concurrency key is shared (e.g.,
+  based on the branch name or workflow name), the new run cancels the already-running
+  check for the previous queued PR.
+
+  The cancelled PR's required check fails or is marked cancelled, causing GitHub to
+  remove that PR from the merge queue and requeue it. The requeued PR triggers a new
+  run — which cancels the next PR's check — creating an infinite cascade. No PR
+  successfully merges.
+
+  The merge queue is designed to serialize merges safely. Adding `cancel-in-progress:
+  true` to `merge_group` workflows defeats the serialization and creates cascading
+  failures.
+fix: |
+  For `merge_group` events, always use `cancel-in-progress: false` (or omit it).
+  Each merge queue entry must complete independently. To keep cancellation for regular
+  pull_request events (to cancel superseded draft checks), use a conditional expression:
+
+  concurrency:
+    group: ci-${{ github.event.merge_group.head_sha || github.head_ref || github.ref }}
+    cancel-in-progress: ${{ github.event_name == 'pull_request' }}
+
+  This cancels in-progress runs for updated PRs but never cancels merge queue checks.
+fix_code:
+  - language: yaml
+    label: "Safe: conditional cancel-in-progress for merge_group + pull_request"
+    code: |
+      on:
+        pull_request:
+        merge_group:
+
+      concurrency:
+        # Use merge_group head SHA for unique per-entry key; fall back for PR events
+        group: ci-${{ github.event.merge_group.head_sha || github.head_ref || github.ref }}
+        # Only cancel for PRs (draft updates), NEVER for merge queue entries
+        cancel-in-progress: ${{ github.event_name == 'pull_request' }}
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: npm test
+  - language: yaml
+    label: "Broken: cancel-in-progress true on merge_group causes cascade"
+    code: |
+      # DO NOT USE — cancels queued merge checks, nothing merges
+      on:
+        merge_group:
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        cancel-in-progress: true
+prevention:
+  - "Never use cancel-in-progress: true when the workflow is triggered by the merge_group event."
+  - "Use github.event.merge_group.head_sha in the concurrency key to ensure each queue entry gets a unique group."
+  - "Test merge queue behavior by simultaneously queuing 2-3 PRs and confirming all checks complete."
+  - "If combining pull_request and merge_group triggers, make cancel-in-progress conditional on the event type."
+docs:
+  - url: "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue"
+    label: "GitHub Docs: Managing a merge queue"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#merge_group"
+    label: "Events that trigger workflows: merge_group"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-concurrency"
+    label: "GitHub Docs: Controlling concurrency"

package/errors/concurrency-timing/reusable-workflow-github-workflow-context-cancel.yml

@@ -0,0 +1,124 @@
+id: concurrency-timing-019
+title: "Reusable Workflow Inherits Caller's ${{ github.workflow }} — Concurrency Group Collision Cancels Caller"
+category: concurrency-timing
+severity: error
+tags:
+  - reusable-workflow
+  - workflow-call
+  - concurrency
+  - github-workflow-context
+  - cancel-in-progress
+  - context-inheritance
+patterns:
+  - regex: "Run was cancelled|Canceling since a higher priority waiting request"
+    flags: "i"
+  - regex: "called workflow.*cancel|reusable.*workflow.*concurrency"
+    flags: "i"
+  - regex: "github\\.workflow.*concurrency group|concurrency.*reusable"
+    flags: "i"
+error_messages:
+  - "Run was cancelled"
+  - "Canceling since a higher priority waiting request for '...' exists"
+  - "This run was cancelled because another run in the same concurrency group was started"
+root_cause: |
+  When a called (reusable) workflow uses `${{ github.workflow }}` in its `concurrency.group`
+  expression, it inherits the CALLER workflow's name — not its own file name. This causes both
+  the caller and the called workflow to join the same concurrency group, leading to cascading
+  cancellations.
+
+  Example: Caller workflow named "CI" calls "Deploy" as a reusable workflow. Both define:
+    concurrency:
+      group: ${{ github.workflow }}-${{ github.ref }}
+      cancel-in-progress: true
+
+  At runtime, `github.workflow` inside "Deploy" evaluates to "CI" — the same string as the
+  caller. When the called workflow starts, `cancel-in-progress: true` fires and cancels the
+  still-running caller workflow.
+
+  This is documented behavior: the GitHub Actions runner passes the caller workflow's
+  `github` context to all called workflows. The called workflow has no way to determine its
+  own filename via context expressions alone.
+
+  The GitHub Docs now include an explicit warning: "A called workflow uses the name of its
+  caller workflow in ${{ github.workflow }}, so using this context as the value of
+  jobs.<job_id>.concurrency.group in both caller and called workflows will cause the caller
+  workflow to be cancelled when the called workflow runs."
+
+  Source: actions/runner#3205 (github.workflow context variable causes child workflow runs to
+  be prematurely canceled — opened Mar 2024, closed stale Apr 2025, 0 official fix)
+  Source: GitHub Docs — Using concurrency with reusable workflows
+fix: |
+  Do not use `${{ github.workflow }}` in concurrency group expressions inside reusable
+  (workflow_call) workflows.
+
+  Option A — Hard-code a unique identifier for the called workflow:
+    Use a static string that cannot match the caller's concurrency group.
+
+  Option B — Pass caller context as an explicit input:
+    Accept a `concurrency_key` input from the caller and use that in the called
+    workflow's concurrency group, giving the caller full control.
+
+  Option C — Remove concurrency from the called workflow entirely:
+    If the caller manages concurrency at the job level, the called workflow's internal
+    concurrency is often redundant and causes more harm than good.
+fix_code:
+  - language: yaml
+    label: "caller.yml — standard concurrency group using github.workflow (safe here)"
+    code: |
+      name: CI
+
+      on:
+        push:
+          branches: [main]
+
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        cancel-in-progress: true
+
+      jobs:
+        test:
+          uses: ./.github/workflows/deploy.yml
+          with:
+            environment: staging
+
+  - language: yaml
+    label: "deploy.yml (called) — DO NOT use github.workflow; use a static name instead"
+    code: |
+      name: Deploy
+      # NOTE: when called, github.workflow returns "CI" (caller name), NOT "Deploy"
+
+      on:
+        workflow_call:
+          inputs:
+            environment:
+              type: string
+              required: true
+
+      # ✅ CORRECT: static unique identifier — never collides with caller group
+      concurrency:
+        group: deploy-called-${{ inputs.environment }}-${{ github.ref }}
+        cancel-in-progress: false
+
+      # ❌ WRONG: "CI-refs/heads/main" == caller's group → caller gets cancelled
+      # concurrency:
+      #   group: ${{ github.workflow }}-${{ github.ref }}
+      #   cancel-in-progress: true
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: ./deploy.sh ${{ inputs.environment }}
+prevention:
+  - "Never use `${{ github.workflow }}` in concurrency group expressions inside reusable (workflow_call) workflows."
+  - "Use hard-coded or input-derived identifiers in called workflow concurrency groups to ensure uniqueness."
+  - "If the caller already manages concurrency at the job level, omit concurrency from the called workflow entirely."
+  - "Test by triggering two back-to-back runs and confirming neither cancels the other unexpectedly."
+docs:
+  - url: "https://docs.github.com/en/actions/sharing-automations/reusing-workflows"
+    label: "GitHub Docs: Reusing workflows — concurrency warning"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-concurrency"
+    label: "GitHub Docs: Using concurrency in GitHub Actions"
+  - url: "https://github.com/actions/runner/issues/3205"
+    label: "actions/runner#3205: github.workflow context causes child workflow cancellation"

package/errors/concurrency-timing/runner-scale-set-jobs-never-start.yml

@@ -0,0 +1,123 @@
+id: concurrency-timing-018
+title: "Jobs Dispatched to Runner Scale Set Never Start — Label Mismatch or Registration Failure"
+category: concurrency-timing
+severity: error
+tags:
+  - runner-scale-set
+  - self-hosted
+  - job-routing
+  - label
+  - registration
+  - arc
+  - actions-runner-controller
+  - stuck
+patterns:
+  - regex: "Waiting for a runner to pick up this job"
+    flags: "i"
+  - regex: "runner scale set.*not found"
+    flags: "im"
+  - regex: "No runner matching the required labels .*\\[.*\\] is online"
+    flags: "i"
+  - regex: "Could not find any online and idle runners that match the requested labels"
+    flags: "i"
+error_messages:
+  - "Waiting for a runner to pick up this job..."
+  - "No runner matching the required labels '[self-hosted, production-scale-set]' is online."
+  - "Could not find any online and idle runners that match the requested labels."
+  - "This job was lost while waiting for a runner. Please re-run the job."
+root_cause: |
+  GitHub Actions runner scale sets (introduced via Actions Runner Controller / ARC and the
+  newer Go-based runner scale set client) dispatch jobs to a dynamically scaling pool of
+  runners. When a job is queued but no runner starts to process it, several misconfiguration
+  scenarios cause the job to wait indefinitely:
+
+  1. **Label mismatch**: The workflow's `runs-on` label does not exactly match the
+     runner scale set's configured name/label. Labels are case-sensitive. A workflow
+     specifying `runs-on: prod-scale-set` will never match a scale set registered as
+     `Prod-Scale-Set` or `production-scale-set`.
+
+  2. **Registration failure**: The scale set client failed to register with GitHub
+     (bad `githubConfigUrl`, expired PAT, GitHub App credentials rotated) but no alert
+     was generated. The runner group appears in the UI but receives no jobs because it
+     has zero healthy, registered instances.
+
+  3. **Min runners set to 0, scale-up blocked**: The scale set is configured with
+     `minRunners: 0` and depends on job events to scale up, but a network policy,
+     firewall rule, or Kubernetes resource quota prevents new runner pods from starting.
+     The broker sees a healthy scale set but new runners cannot provision.
+
+  4. **Runner listener terminated unexpectedly**: The runner listener process (the
+     manager component) crashed silently. GitHub shows the scale set as registered but
+     it has no workers accepting the dispatch message.
+
+  5. **Org/repo runner group restriction**: The runner group containing the scale set
+     has repository-access restrictions — the requesting repo is not in the allowed list.
+
+  Jobs in this state do not produce an explicit error in the Actions log; they are
+  stuck in "Waiting for a runner" indefinitely until they hit the 35-day job timeout
+  or are manually cancelled.
+fix: |
+  1. **Verify label exact-match**: Compare `runs-on:` value in the workflow against
+     the registered runner scale set name in Settings → Actions → Runners. Must be
+     an exact case-sensitive match.
+
+  2. **Check registration health**: In the runner scale set client logs (or ARC
+     controller pod logs), look for registration errors. Re-create credentials if
+     the GitHub App or PAT has been rotated.
+
+  3. **Inspect runner group access**: Settings → Actions → Runner groups → the group
+     containing your scale set → confirm the requesting repo is listed under
+     "Repository access".
+
+  4. **Check scale-up events**: Review Kubernetes events (`kubectl get events -n <ns>`)
+     for resource quota exceeded, image pull failures, or scheduling constraints that
+     prevent runner pods from starting.
+
+  5. **Restart the runner listener**: If the manager/listener process crashed, restart
+     the scale set client deployment or the ARC AutoscalingRunnerSet resource.
+fix_code:
+  - language: yaml
+    label: "Workflow: verify exact label matches your scale set registration name"
+    code: |
+      jobs:
+        build:
+          # Must exactly match the scale set name registered in Settings → Actions → Runners
+          # e.g., registered as "prod-k8s-runners" → use exactly "prod-k8s-runners"
+          runs-on: prod-k8s-runners    # ← exact case-sensitive match required
+          steps:
+            - uses: actions/checkout@v4
+            - run: echo "Running on scale set runner"
+  - language: yaml
+    label: "Diagnose label and runner group access via GitHub API"
+    code: |
+      # List runner groups for an org (requires admin PAT):
+      # GET /orgs/{org}/actions/runner-groups
+      #
+      # List repos allowed to use a specific runner group:
+      # GET /orgs/{org}/actions/runner-groups/{group_id}/repositories
+      #
+      # List self-hosted runners in a group:
+      # GET /orgs/{org}/actions/runner-groups/{group_id}/runners
+      #
+      # Using gh CLI:
+      # gh api /orgs/MY-ORG/actions/runner-groups --jq '.[].runners_url'
+      - name: Print runner labels (inside the running job)
+        run: |
+          echo "Runner name: ${{ runner.name }}"
+          echo "Runner OS: ${{ runner.os }}"
+          echo "Runner arch: ${{ runner.arch }}"
+prevention:
+  - "Treat runner scale set names as API contracts — document them in a shared wiki and never rename without updating all workflow files."
+  - "Set up monitoring on the runner scale set listener/controller pod — alert if it crashes or stops processing dispatches."
+  - "Configure `minRunners: 1` on production scale sets to keep at least one warm runner active; `minRunners: 0` requires flawless scale-up on every job dispatch."
+  - "Add a `timeout-minutes` on jobs dispatched to scale sets so stuck jobs fail fast rather than consuming the 35-day wait limit."
+  - "After rotating GitHub App credentials or PATs used by the scale set client, immediately verify a test workflow completes on the scale set."
+docs:
+  - url: "https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller"
+    label: "GitHub Docs: Deploying runner scale sets with Actions Runner Controller"
+  - url: "https://github.blog/changelog/2026-02-05-github-actions-early-february-2026-updates/"
+    label: "GitHub Changelog: Actions early February 2026 updates (runner scale set client)"
+  - url: "https://github.com/orgs/community/discussions/171291"
+    label: "Community Discussion: Runner scale set jobs not being dispatched"
+  - url: "https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups"
+    label: "GitHub Docs: Managing access to self-hosted runners using groups"

package/errors/concurrency-timing/runner-temp-dir-race-concurrent-workers.yml

@@ -0,0 +1,90 @@
+id: concurrency-timing-022
+title: "Concurrent Self-Hosted Runner Workers Share _temp — Cancelled Job Wipes Active Job Files"
+category: concurrency-timing
+severity: error
+tags:
+  - self-hosted-runner
+  - temp-directory
+  - race-condition
+  - worker
+  - non-ephemeral
+patterns:
+  - regex: "Missing file at path:.*_temp.*_runner_file_commands.*set_output"
+    flags: "i"
+  - regex: "TempDirectoryManager.*Cleaning runner temp folder"
+    flags: "i"
+  - regex: "We are not yet checking the state of jobrequest.*Cancel running worker right away"
+    flags: "i"
+  - regex: "Worker finished for job.*Code: 102"
+    flags: "i"
+error_messages:
+  - "Error: Missing file at path: /home/runner/work/_temp/_runner_file_commands/set_output_<uuid>"
+  - "[TempDirectoryManager] Cleaning runner temp folder: /home/runner/work/_temp"
+  - "[JobDispatcher] We are not yet checking the state of jobrequest ... Cancel running worker right away."
+  - "Worker finished for job ... Code: 102"
+root_cause: |
+  When two jobs are dispatched to the same non-ephemeral self-hosted runner in quick succession,
+  the runner cancels the first Worker and immediately spawns a second Worker — both run
+  simultaneously for several seconds. Both Workers share the same _temp directory
+  (_work/_temp). The cancelled Worker TempDirectoryManager cleanup fires 10-30 seconds
+  after cancellation, which is after the new Worker has already created its file-command
+  pipes (_runner_file_commands/set_output_*, step_summary_*) in the shared _temp.
+
+  The cleanup unconditionally wipes the entire _temp folder, deleting the new Worker active
+  file command pipes mid-step. The new job exits with code 102
+  (runner infrastructure failure), not a workflow step failure.
+
+  Root issue: JobDispatcher does not wait for the previous Worker process to exit before
+  spawning the new Worker. Both PIDs coexist on the same temp path.
+  Reported in actions/runner#4357, Apr 2026; fix proposed in PR #4371.
+fix: |
+  Primary fix (recommended): Use ephemeral runners.
+  Ephemeral runners (--ephemeral) start fresh for each job and never receive a second job
+  assignment, eliminating the race entirely.
+
+  Alternative: Limit concurrency on the runner group.
+  If ephemeral mode is not an option, configure the workflow concurrency group to prevent
+  two workflows from targeting the same runner label simultaneously.
+
+  Alternative: Use a per-job container.
+  Run each job inside an isolated Docker container on the self-hosted runner so
+  the file paths do not collide between concurrent jobs.
+fix_code:
+  - language: yaml
+    label: "Use ephemeral self-hosted runner (recommended)"
+    code: |
+      # Register your runner with --ephemeral flag:
+      # ./config.sh --url https://github.com/org/repo --token TOKEN --ephemeral
+      #
+      # In your workflow, the runner label stays the same:
+      jobs:
+        build:
+          runs-on: [self-hosted, linux, x64]
+          steps:
+            - uses: actions/checkout@v4
+            - run: make build
+  - language: yaml
+    label: "Limit per-runner concurrency via workflow concurrency group"
+    code: |
+      concurrency:
+        group: self-hosted-runner-${{ github.ref }}
+        cancel-in-progress: false   # Queue instead of cancel
+
+      jobs:
+        build:
+          runs-on: [self-hosted, linux, x64]
+          steps:
+            - uses: actions/checkout@v4
+            - run: make build
+prevention:
+  - "Use ephemeral runners for all self-hosted CI workloads — they also improve security and reduce state leakage between jobs."
+  - "Avoid non-ephemeral runners for workflows that run frequently; shorter intervals increase the chance of dispatch overlap."
+  - "Monitor for exit code 102 in workflow logs — it indicates a runner infrastructure failure, not a step failure."
+  - "Track actions/runner#4357 for an official fix to TempDirectoryManager shared-path cleanup behavior."
+docs:
+  - url: "https://github.com/actions/runner/issues/4357"
+    label: "actions/runner#4357 — TempDirectoryManager race condition (Apr 2026)"
+  - url: "https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling"
+    label: "Ephemeral runners for autoscaling"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-concurrency"
+    label: "Using concurrency"