Release timeout falsely reports workflow approval after CI has already started #145

Observed failure and immutable source

At main 247b95e6214f687d0d838d1685cc0e99db664cd6, release.yml initializes awaiting_approval=0 once before the merge loop, sets it to 1 when a run is action_required/waiting, and never resets it when a later poll reports no approval-pending runs.

Daily Release 39015290805 timed out at 08:37:04 UTC on October 17 and told the maintainer to approve the CI run. But the same log repeatedly reports both required tests in progress, including at 08:37:03. Node 22 started at 08:13:14 and passed at 08:38:02; Node 26 started at 08:12:55 and passed at 08:39:04. This was a slow-check timeout, not an approval still required at timeout.

At the 09:15 UTC read, release PR #144 remains open at 328e284cd30afb2811998fc6d0f02e78994d537c, its checks are green, and the latest GitHub release is still v2026.10.16. Publication/tagging steps were skipped. This report does not authorize a merge, retry, or release.

Bounded reproduction

Run the workflow's approval-state assignments in isolation, without any gh/git/network calls:

1. Initialize awaiting_approval=0
2. First poll: pending_runs is nonempty, so the existing conditional sets awaiting_approval=1
3. Later poll: pending_runs is empty because CI is now in_progress; the same conditional leaves awaiting_approval at 1
4. Execute the deadline diagnostic conditional: it selects 'awaiting workflow approval'

Observed exit 0 and approval-required diagnostic despite current approval-required=false. Source inspection finds only three uses: initialization line 354, setting line 479, deadline branch line 484.

Expected: terminal diagnostics reflect the latest successfully observed approval/check state and distinguish slow-running checks from a genuinely approval-blocked workflow. Actual: a historical approval observation permanently selects the approval message, directing the maintainer to an action that is no longer applicable.

Goal and impact

The protected-release merge loop introduced in PR #33 deliberately keeps publication behind verified merge and diagnoses a bounded wait. Preserve that safety behavior. The defect is stale state in the recovery guidance; increasing timeouts or bypassing checks is not required to correct it. Today it obscures why a fully green release PR is still unpublished.

Regression acceptance

• action_required -> in_progress -> deadline reports checks still settling, without claiming approval is currently required
• action_required -> action_required -> deadline still reports the actual pending run
• action_required -> successful checks/merge does not emit a stale approval blocker
• An unavailable run-state read is distinguished from a verified empty result
• No reduction to required checks, review gates, permissions or publication protections

Scope: hosted log/check evidence and a minimal isolated state-transition reproduction, not a full release replay or newly run package suite. All-status repository issues/PRs and all 131 canonical PM records were checked for an existing owner before filing.