Recover a failed change
Helmhive never retries a repository write on its own. When a step stops, the change page names what happened and offers one safe next action. This page maps the message you see to what to do.
Read the failure
Section titled “Read the failure”The change page shows one of these headings, the server’s message, and guidance:
| Heading | What happened | Next step |
|---|---|---|
| Independent review requested changes | The review verdict was not approve, a check failed, or a blocking finding exists. | A Developer reviews the findings, then anyone who can request changes prepares a fresh plan. The previous approval cannot be reused. |
| Implementation exceeded the approved paths | The runner changed files outside the plan. Helmhive rejected the result before delivery. | Review the unexpected paths, then prepare and approve a fresh exact plan. No path is added automatically. |
| This workflow was cancelled safely | A Developer cancelled it, or the service’s authority changed (policy revised, repository access lost, service paused). | Nothing later runs for that execution. Prepare a fresh plan when the cause is resolved. |
| This workflow stopped safely | Any other failure, such as no eligible runner or a stale source. | Resolve the named cause, then use the next safe action on the page. |
Requesters see a plain-language category. Developers see the underlying failure code and message.
Common causes and where to fix them
Section titled “Common causes and where to fix them”- No online runner matches the profile and execution environment. A workspace administrator checks AI for runner readiness, the service’s environment assignment, and profile model mappings. The change page links there when you hold the settings capability.
- Plan stale or expired. The repository head, policy, capabilities, or environment binding changed, or seven days passed. Prepare a fresh plan.
- Repository base changed during delivery. Prepare a fresh plan on the new base.
- Bot not allowlisted or lacks write access. An administrator checks pull-request delivery for that repository.
- Repository access lost. The source can no longer see the repository. Restore access at the provider, synchronize the source, and activate the service again.
Do not work around it
Section titled “Do not work around it”Broadening repository or service authority to get past a failure defeats the point of the workflow. Fix the named prerequisite, prepare a fresh plan, and let the checks run again.