PR-creation step can silently fail, leaving an orphan branch with no PR #111

Closed
opened 2026-07-17 11:22:47 +02:00 by ops · 1 comment
Member

Summary

When a dev agent finishes work on an issue, it can commit and push a branch but fail to open the PR, leaving an orphan branch that nobody sees. This surfaced on gitea/ops issue #12: @senior committed all the correct edits to branch ai/issue-12 (commit 55e00871, parent = current main), but no PR was ever opened, so neither the maintainer nor @qa had anything to review. @ops had to open the PR manually (PR #110).

Impact

  • Completed work looks "lost" — the maintainer sees no PR and assumes the agent did nothing.
  • Requires manual intervention to recover (find the branch, verify the commit, open the PR by hand).
  • Silent failure: nothing reports that the PR step didn't fire.

Expected behavior

After pushing the branch, the flow should either:

  1. Reliably open the PR (head ai/issue-<n>main, linking the issue), or
  2. If PR creation fails, report loudly in the issue thread (with the branch name and the error) instead of leaving an orphan branch silently.

Where to look

The PR-creation step in the agent workflow (.gitea/workflows/ in this repo — agent.yml and its scripts/). Check the branch/commit path where the PR-open call is made: whether it's conditional, whether its failure is swallowed, and whether the exit status is checked.

Repro (observed)

  • Branch ai/issue-12 exists with commit 55e00871 (3 files changed correctly).
  • No PR existed for that branch until opened manually as #110.

Notes

Filed by @ops at the maintainer's request. This is a code fix in the agents workflow (not an instance-admin change), so it's for a dev to pick up.

## Summary When a dev agent finishes work on an issue, it can **commit and push a branch but fail to open the PR**, leaving an orphan branch that nobody sees. This surfaced on gitea/ops issue #12: @senior committed all the correct edits to branch `ai/issue-12` (commit `55e00871`, parent = current `main`), but **no PR was ever opened**, so neither the maintainer nor @qa had anything to review. @ops had to open the PR manually (PR #110). ## Impact - Completed work looks "lost" — the maintainer sees no PR and assumes the agent did nothing. - Requires manual intervention to recover (find the branch, verify the commit, open the PR by hand). - Silent failure: nothing reports that the PR step didn't fire. ## Expected behavior After pushing the branch, the flow should **either**: 1. Reliably open the PR (head `ai/issue-<n>` → `main`, linking the issue), **or** 2. If PR creation fails, **report loudly** in the issue thread (with the branch name and the error) instead of leaving an orphan branch silently. ## Where to look The PR-creation step in the agent workflow (`.gitea/workflows/` in this repo — `agent.yml` and its `scripts/`). Check the branch/commit path where the PR-open call is made: whether it's conditional, whether its failure is swallowed, and whether the exit status is checked. ## Repro (observed) - Branch `ai/issue-12` exists with commit `55e00871` (3 files changed correctly). - No PR existed for that branch until opened manually as #110. ## Notes Filed by @ops at the maintainer's request. This is a code fix in the agents workflow (not an instance-admin change), so it's for a dev to pick up.
Owner

Fixed via #112 / PR #113 — publish.sh now surfaces both PR-create and git-push failures as loud comments on the issue thread (branch name + HTTP status + Gitea error message) instead of silently posting the plain reply.

Fixed via #112 / PR #113 — publish.sh now surfaces both PR-create and git-push failures as loud comments on the issue thread (branch name + HTTP status + Gitea error message) instead of silently posting the plain reply.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/agents#111