Release workflow: auto-retry cannot rerun its active parent run

[100yenadmin]

Summary

The Auto Retry on Build Failure job in .github/workflows/build-and-release.yml cannot rerun its own workflow run while that same job is still active.

Observed on the first v2.1.33 release attempt:

• parent run: https://github.com/100yenadmin/evaOS-GUI/actions/runs/29238215096
• auto-retry job: https://github.com/100yenadmin/evaOS-GUI/actions/runs/29238215096/job/86779516638
• after its five-minute cooldown, the rerun API returned HTTP 403 because the workflow was still running
• no second attempt, run, or build job was created

Root cause

The job calls the Actions rerun endpoint for ${{ github.run_id }} from inside that same still-active run. GitHub does not allow a run to be rerun until it has completed. The job itself prevents completion until after the API call, so the design cannot succeed.

Expected behavior

Release retries must be bounded and auditable without creating an infinite dispatch loop. Acceptable outcomes include:

• remove the misleading auto-retry and require an explicit operator rerun; or
• move retry orchestration to a separate workflow triggered after workflow_run completion, with an exact run-attempt/input guard.

The replacement must preserve manual-only beta release acknowledgement, exact target-platform inputs, immutable ref evidence, and no tag/release creation after a failed build.

Proof boundary

This defect did not cause the v2.1.33 build failure. The first build failed deterministically in the Python runtime inventory gate and is addressed by #676. This issue tracks the separate fact that the advertised automatic recovery path did not run.

Parent tracker: #623.

[coderabbitai]

🔗 Related PRs

#271 - fix: distribute beta RC through GitHub Releases [closed]
#375 - Expose Workbench functional smoke workflow on default branch [merged]
#399 - Register local signed DMG manifest workflow [merged]
#517 - [codex] Pass pinned bridge ref into Manual Build [merged]
#636 - fix(evaos): enforce no-ACP release packaging [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #677 - Release workflow: auto-retry cannot rerun its active parent run
State: open; milestone: Workbench Runtime Reliability Release Train

Related issues/PRs: #676, #623.
Existing labels: bug, evaos, public-beta, ready-for-agent, area:release, kind:integration, blocked, release-train:runtime-reliability.
Suggested labels: none.
Suggested owners: none.

Related context

• fix(release): keep Python inventory stable through packaging #676 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• Roadmap: Workbench runtime reliability release train #623 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: Release workflow: auto-retry cannot rerun its active parent run - ## Summary The Auto Retry on Build Failure job in .github/workflows/build-and-release.yml cannot rerun its own workflow run while that same job is still active. Observed on the first v2.1.33 release attempt: -
Product fit: Product/UX-sensitive issue; review against repo vision and user flow quality, not only technical P0/P1 risk.
Implementation wedge: Ship the smallest user-visible path or prototype that can be smoke-tested against the intended experience.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.
• Current market/product examples, capped and cited, only when they change implementation direction.

Acceptance criteria:

• Add explicit acceptance criteria before implementation is considered done.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• UX/product smoke or screenshot proof when implementation changes user flow.
• Contract or degraded-mode proof before runtime promotion.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.
• Technical severity alone can miss product/UX regressions; include product-manager review framing.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [enabled] current_market_examples: Use for product/UX/market positioning issues with freshness dates.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.