CI: auto-assign shares one concurrency group for all issues/PRs — a burst silently drops the pending assignment #302

Problem

.github/workflows/auto-assign.yml:7-9 puts every run in one concurrency group:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false

The workflow triggers only on issues: [opened] and pull_request_target: [opened, reopened, synchronize]. For both event types github.ref is the default/base branch (refs/heads/main) — it never contains the issue or PR number. So every auto-assign run in the repository shares the single group Auto Assign-refs/heads/main.

GitHub's concurrency semantics (docs: "Control the concurrency of workflows and jobs"): at most one run can be running and at most one can be pending in a group (queue: single is the default). When a new run is queued, any existing pending run in the group is canceled and replaced. cancel-in-progress: false protects only the running run, not the pending one.

Consequence: if three issues/PRs are opened in quick succession while one auto-assign run is in progress, the second run is queued and then silently replaced by the third. The middle issue/PR never gets its assignment run — the job's only effect (gh issue/pr edit --add-assignee dezren39) never executes for it, and nothing retries it. The run shows as cancelled, indistinguishable from intentional cancellation.

This is the same defect already filed for the sibling forks (developing-today/opencode#74, developing-today/openchamber#72, dezren39/nix#413). In this repo it was first noted as an unverified REVIEW-FINDING on PR #289 in the sweep backlog; the pending-replacement semantics are now verified against GitHub's concurrency docs, on the same basis as those filings.

Evidence

• auto-assign.yml (verified byte-identical via the GitHub API on main 4bf48d4e): triggers at lines 2-6, concurrency group at lines 7-9, single job whose only step assigns dezren39 to github.event.issue.number || github.event.pull_request.number.
• GitHub concurrency docs: "there can be at most one running job or workflow in a concurrency group at any time… By default, any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place"; queue: single (default) — "At most one job or workflow run can be pending in the concurrency group. When a new job or workflow run is queued, any existing pending job or workflow run in the same group is canceled and replaced."
• Correct in-family precedents: openchamber's issue-intake groups by github.event.issue.number; opencode's pr-standards/pr-management group by pull_request.number; this workflow itself already distinguishes targets with github.event.issue.number || github.event.pull_request.number for the assignment step — the group just doesn't use it.
• The other workflow + ref groups in this repo are not affected the same way: for pull_request events github.ref is refs/pull/<number>/merge, i.e. per-PR. Only the issues / pull_request_target / issue_comment shapes collapse to the default branch.

Why it matters

Auto-assign is the routing step that puts a maintainer on every new issue and PR. A burst of activity — exactly when assignment matters most (e.g. the sweep/creator lanes opening several PRs in a row, as the recent run history shows) — can silently drop one of the assignments with no failure, no notification, and no retry.

Suggested fix

Key the group by the target, reusing the expression the workflow already uses for the assignment:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.issue.number || github.event.pull_request.number }}
  cancel-in-progress: false

Different issues/PRs then never block each other; repeated events for the same target still serialise, and a replaced pending duplicate is harmless because assignment is idempotent. (queue: max on the shared group would also stop the drops, but serialises unrelated targets for no benefit.)

Acceptance criteria

• Two auto-assign runs for different issue/PR numbers can be running/pending at the same time (different concurrency groups).
• A burst of ≥3 opened events in quick succession results in every target being assigned — no run cancelled with "a newer run was queued for the same concurrency group" for a different target.
• Repeated synchronize events for the same PR still do not run concurrently with each other.
• Workflow YAML parses and the assignment step is unchanged.