CI/merge hygiene: 'Workflows' check hangs pending; stacked-PR base deletion closes dependents

[ndreno]

Two related pain points surfaced while merging the 0.10.0 work (#157, #159/#160, #161, #162). Both forced manual intervention.

1. The Workflows (zizmor) check reports pending after its run succeeds

The workflows job in ci.yml (name: Workflows, runs zizmor) reliably shows as pending in gh pr checks and keeps the PR mergeStateStatus: BLOCKED even after its workflow run has concluded success (the job has conclusion=success and a completedAt, but the check status never reconciles). Observed on every PR in the 0.10.0 batch, each requiring an --admin merge.

Effect: no PR can auto-merge on green; the required check never reports green to branch protection.

Directions to investigate:

• The job runs on push with no needs/paths filter, so it may register a check context that branch protection tracks differently from the PR head SHA (duplicate/hung context).
• Confirm whether the required-check name in branch protection matches exactly one context.
• Consider gating it behind the changes filter or giving it a stable check name, or moving the workflow-audit into the fmt/clippy fast job.

2. Deleting a base branch on merge closes stacked PRs instead of retargeting

Merging #157 with --delete-branch while #159 was stacked on feat/waf-response-phase closed #159 rather than retargeting it to main; it had to be reopened as a fresh PR (#160) after rebasing off the now-merged base. GitHub retargets dependent PRs only in some cases; a deleted base branch generally closes them.

Mitigations:

• Open stacked PRs against main from the start, or
• Merge the base PR without --delete-branch until the stacked PR is retargeted, then delete, or
• Document the sequence in CONTRIBUTING/release notes.

Neither is a correctness bug in the gateway; both are CI/release-process hygiene that cost time this cycle.

[ndreno]

Root-caused. Two separate things were conflated under "the Workflows check hangs."

1. The spurious "Workflows" check (fixed in #167). ci.yml triggers on issue_comment (for /bench), and the workflows (zizmor) job had no event guard, so every comment on a PR fired a CI run whose only active job was zizmor. Those comment-triggered runs are what produced confusing "Workflows" check runs. #167 adds if: github.event_name != 'issue_comment' to the job; now a comment runs nothing unless it is an authorized /bench.

2. The actual merge-BLOCKED state (needs repo settings). Branch protection on main requires only Build, Unit Tests, Integration Tests, not "Workflows", with strict: true (require branches up to date before merging). During the 0.10.0 merge train, each merge advanced main and made the other open PRs out of date, which shows as BLOCKED and forces a branch update plus a full CI re-run, or an admin merge. That is the friction that made me --admin merge each PR, not the zizmor check.

Recommendation for the maintainer (requires settings access):

• Either drop strict on the main branch protection, or
• Enable a GitHub merge queue for main, which updates and tests each PR against the queue head automatically so stacked/queued PRs stop invalidating each other.

The stacked-PR base-branch-deletion pitfall from the original issue still stands as a process note: merge a base PR without --delete-branch until the stacked PR is retargeted (or open stacked PRs against main from the start).

[ndreno]

Update: strict is now off on the main branch protection (required checks Build / Unit Tests / Integration Tests preserved). PRs will no longer be BLOCKED just for being behind main, which removes the merge-train friction and the need for admin merges. Combined with #167 (guarding the zizmor job from comment triggers), this resolves both halves of the issue. The stacked-PR base-deletion note remains as process guidance.