fix(release): wait via list+filter and self-heal missing draft

[BryanFRD]

Summary

The Wait for draft release to be visible step in .github/workflows/publish.yml has been silently breaking the release pipeline since #438 (v4.7.0). v4.7.0 and v4.7.1 published with 0 assets; v4.7.2 stayed in draft state. Downstream consumers (FerrLabs/FerrFlow@v4 resolving to releases/latest/download/ferrflow-linux-x64.tar.gz) hit 404 — FerrGames-Cloud has 10 PRs sitting on main since 2026-05-13T17:22 with no release because of this.

Root cause

The wait step polled gh release view "$TAG" which, in the v4.7.2 Publish run, returned 404 for the freshly-created draft despite the draft existing in the GitHub UI. Verified locally: gh release view v4.7.2 --repo FerrLabs/FerrFlow finds the draft, gh api .../releases/tags/v4.7.2 returns 404 (the REST endpoint excludes drafts entirely). The CLI behavior in the runner appears version-skewed.

Compounding bug: monorepo.rs:1339 swallows create_release failures as warnings, so a transient API error during ferrflow release --draft lets the workflow push the tag without ever creating the release. Filed as a follow-up in the comment.

Fix

1. Switch to list+filter via gh api /releases?per_page=100 --jq '.[] | select(.tag_name == "$TAG") | .id' — the only stable surface that lists drafts when authenticated.
2. Extend the poll window from 150 s to 300 s — covers slower API propagation observed in past failures.
3. Self-heal: if the wait expires without finding the draft, the step now creates the release itself instead of failing the whole publish. Covers the case where ferrflow's create_release silently warned-and-continued.

Test plan

• CI green (no functional change to anything but the wait step)
• On merge to main, ferrflow auto-cuts v4.7.3 — verify the wait step finds the draft within seconds
• Verify v4.7.3 release ends up with all 6 assets (linux x64/arm64, darwin x64/arm64, windows x64, completions)
• Verify https://github.com/FerrLabs/FerrFlow/releases/latest/download/ferrflow-linux-x64.tar.gz returns 200
• Re-trigger FerrGames-Cloud's main CI release step → succeeds, ships the 10 backlog PRs

[Copilot]

Pull request overview

Hardens the Wait for draft release to be visible step in the publish workflow after observations that gh release view was returning 404 on freshly created drafts (causing v4.7.0/v4.7.1 to publish with 0 assets and v4.7.2 to remain in draft). Switches to a list+filter strategy via the REST GET /releases endpoint, doubles the poll window, and adds a self-heal fallback that creates the draft if the wait expires.

Changes:

• Replace gh release view "$TAG" polling with gh api repos/$REPO/releases?per_page=100 filtered by tag name through --jq.
• Increase poll attempts from 30 to 60 (≈150s → ≈300s window).
• On timeout, downgrade the error to a warning and create the draft release inline (gh release create --draft ...) instead of failing the job.

Comments suppressed due to low confidence (1)

.github/workflows/publish.yml:145

• 2>/dev/null swallows all errors from the gh api call inside the loop. If authentication is wrong, the token lacks scope, the network is failing, or the API is returning 5xx, the loop will silently iterate all 60 times producing only the generic "not yet visible" message before eventually self-healing — which itself may then fail for the same reason. Consider capturing stderr and emitting it (perhaps only on the final attempts, or every Nth iteration) so the actual root cause is visible in the workflow log instead of being hidden behind a 5-minute timeout.

            ID=$(gh api "repos/$REPO/releases?per_page=100" \
                   --jq ".[] | select(.tag_name == \"$TAG\") | .id" 2>/dev/null \
                   | head -n1)

[github-actions]

Benchmark

Details

Benchmark suite	Current: f7da982	Previous: 0b5fe57	Ratio
full_check_flow/100_commits	2769876 ns/iter (± 12948)
full_check_flow/1000_commits	28101813 ns/iter (± 216289)

This comment was automatically generated by workflow using github-action-benchmark.