pull_request workflows stopped firing: every required check reads ABSENT, nothing can merge

[MichaelTaylor3d]

Task

pull_request-triggered workflows have stopped firing in this repo. Every required status check reads ABSENT — never ran on this commit, so no PR here can satisfy §2.4a and nothing can merge. Restore them.

Context

Blocking #7 (was #6), which is on the critical path of epic https://github.com/DIG-Network/dig_ecosystem/issues/3161 — its published 0.3.1 ships internally split, so consumers cannot escape by bumping, and dig-node's whole 0.26 holdout is waiting behind it.

What was measured

The last successful pull_request runs were on merge-sha 6d6bf42. After that, every event produced only dynamic (CodeQL) runs:

attempt	head	result
lane push	ec28f69	CodeQL only
push	defbe4d	CodeQL only
amend + force-push	b2f3bb9	CodeQL only
close → reopen ×2	—	fired once on merge-sha b0cd8fe, never attached to the PR head
fresh PR (#7), same branch	b2f3bb9	CodeQL only

A brand-new PR firing nothing is the strongest signal: opened is a default trigger type and cannot be missed.

Ruled out — do not re-check these

• Not a platform outage. Control run in the same window: dig-clvm, dig-evidence and dig-social-graph all fired pull_request runs normally (5, 3 and 3 respectively).
• Not repo/Actions config. enabled=true, allowed_actions=all, visibility=public (so minutes are free and unmetered), archived=false, disabled=false. All six workflows report state: active.
• Not the workflow files. git diff origin/main HEAD -- .github/ is empty — byte-identical to main, which fires fine. ci.yml has pull_request: branches: [main]; the PR's base is main.
• Not approval-gated. status=waiting → 0 runs, status=action_required → 0 runs.
• Not a draft-state issue. Reproduced with draft=false.

Scope

Find why pull_request events stop reaching Actions in this repo and restore them. Likely worth checking: org-level Actions policy or a required-workflow rule scoped to this repo, repository rulesets, and whether any other DIG repo shows the same symptom (chia-block-listener showed 0 pull_request runs in the same sweep and may be a second instance — verify before assuming).

Evidence

Fixed when a push to a PR branch here produces pull_request runs and .claude/scripts/check-merge-preconditions.sh --repo DIG-Network/dig-chainsource-interface --pr 7 exits 0.

Do NOT work around it by merging

--admin past four ABSENT required checks would ship a version bump and a new test with no CI evidence at all — precisely the "absent reads as still-coming-in" trap CLAUDE.md §2.4a documents. The PR stays open until the checks run.

[MichaelTaylor3d]

Root-caused and resolved. This is NOT a repo or platform fault.

ci.yml uses concurrency: group: ci-${{ github.ref }} with cancel-in-progress: true. A run that ends in startup_failure can wedge permanently inside that group for refs/pull/6/merge — it reports queued to the run list while the cancel endpoint refuses it as already completed. Every subsequent event on that PR is then cancelled against the wedged member and never runs, which is why all four required contexts read ABSENT.

That explains every observation in this ticket, including the ones that ruled out the usual causes: the workflow files, Actions config, approval state and draft state were all fine, and CodeQL kept firing because it is a dynamic workflow outside that concurrency group.

The escape is a new PR ref, not a new SHA. Rerun, close/reopen, and a force-pushed new SHA all stay inside refs/pull/6/merge and all failed. PR #7 on the identical branch and head went green immediately and is merged.

Independently diagnosed by a lane hitting the same wedge in DIG-Network/digs#56 — so it is a recurring shape, not a one-off. Worth considering whether cancel-in-progress should be scoped so a startup_failure cannot poison the group.

[MichaelTaylor3d]

Correction: the diagnosis I closed this with is INCOMPLETE.

The concurrency-wedge explanation predicted that a new PR ref escapes, and it did here (#7 went green immediately and merged). But the same remedy then failed on dig-evidence #3→#4 and chia-block-listener #25→#26 — both fresh PR refs, both still firing only CodeQL with every required check ABSENT.

So the wedge is at most part of the story. Tracking the full pattern across all four repos on the super-repo: https://github.com/DIG-Network/dig_ecosystem/issues/3163

Leaving this closed because this repo is unblocked, but anyone reading it for the general cause should follow that ticket rather than treating this as settled.

[MichaelTaylor3d]

Second correction: the concurrency-wedge diagnosis was WRONG, not merely incomplete.

Root cause was an upstream GitHub Actions incident (critical, 2026-08-26T15:11:58Z-18:01:30Z, https://stspg.io/pg14nv9m3095). Run creation latency reached 23m14s, so the run records did not exist yet and the checks read ABSENT.

The wedge theory is falsified four ways, including that chia-block-listener/ci.yml has no concurrency: block at all and was affected identically.

And the remedy I credited never worked. This repo's runs for ec28f69b appeared at 16:37:23 — before PR #7 was opened at 16:38:35. The queue drained on its own; the new PR ref did nothing. #7 merging was correct, but not for the reason recorded here.

Full analysis and the resulting script fix: https://github.com/DIG-Network/dig_ecosystem/issues/3163

Staying closed — this repo was never at fault.