fix: dev-poll abandons fresh PRs — stale branch check fails on unfetched refs #248

New issue

Closed

opened 2026-04-05 18:22:45 +00:00 by dev-bot · 0 comments

dev-bot commented

2026-04-05 18:22:45 +00:00

Collaborator

Problem

dev-poll.sh checks if a PR branch is behind main using local git refs:

AHEAD=$(git rev-list --count "origin/${BRANCH}..origin/${PRIMARY_BRANCH}" 2>/dev/null || echo "999")

When the branch was pushed from inside a container worktree (e.g. /tmp/disinto-worktree-240), the host repo's origin/ refs don't know about it — nobody ran git fetch. The rev-list fails, the fallback returns 999, and dev-poll closes the PR as stale:

poll: issue #240 PR #242 is 999 commits behind main — abandoning stale PR

This affects every PR created by the dev agent in a worktree. The PR is closed 5 minutes after creation, before review can happen.

Affects lines 344 and 596 in dev/dev-poll.sh.

Root cause

Two issues:

No git fetch before rev-list — local refs are stale
The error fallback is destructive: || echo "999" assumes "definitely stale" when the safe assumption is "unknown, don't touch"

Proposed solution

Add git fetch origin --prune early in dev-poll, after the lock check and before any git rev-list comparisons. This ensures local refs reflect the remote state. One fetch per poll cycle (~1-2s overhead, negligible compared to the existing API calls).
Change the fallback from || echo "999" to || echo "0" on both lines 344 and 596. If we can't determine how far behind a branch is, the safe default is "not stale" (skip abandonment), not "definitely stale" (close the PR).

Affected files

dev/dev-poll.sh (add git fetch after lock check; change fallback on lines 344 and 596)

Acceptance criteria

git fetch origin --prune runs once per dev-poll cycle, before any stale branch checks
Fallback on rev-list failure is 0 (safe default), not 999 (destructive default)
PRs created from container worktrees are not abandoned on the next poll cycle
Genuinely stale branches (created days ago, many commits behind) are still detected and abandoned

## Problem dev-poll.sh checks if a PR branch is behind main using local git refs: AHEAD=$(git rev-list --count "origin/${BRANCH}..origin/${PRIMARY_BRANCH}" 2>/dev/null || echo "999") When the branch was pushed from inside a container worktree (e.g. /tmp/disinto-worktree-240), the host repo's origin/ refs don't know about it — nobody ran git fetch. The rev-list fails, the fallback returns 999, and dev-poll closes the PR as stale: poll: issue #240 PR #242 is 999 commits behind main — abandoning stale PR This affects every PR created by the dev agent in a worktree. The PR is closed 5 minutes after creation, before review can happen. Affects lines 344 and 596 in dev/dev-poll.sh. ## Root cause Two issues: 1. No git fetch before rev-list — local refs are stale 2. The error fallback is destructive: `|| echo "999"` assumes "definitely stale" when the safe assumption is "unknown, don't touch" ## Proposed solution 1. Add `git fetch origin --prune` early in dev-poll, after the lock check and before any git rev-list comparisons. This ensures local refs reflect the remote state. One fetch per poll cycle (~1-2s overhead, negligible compared to the existing API calls). 2. Change the fallback from `|| echo "999"` to `|| echo "0"` on both lines 344 and 596. If we can't determine how far behind a branch is, the safe default is "not stale" (skip abandonment), not "definitely stale" (close the PR). ## Affected files - dev/dev-poll.sh (add git fetch after lock check; change fallback on lines 344 and 596) ## Acceptance criteria - [ ] git fetch origin --prune runs once per dev-poll cycle, before any stale branch checks - [ ] Fallback on rev-list failure is 0 (safe default), not 999 (destructive default) - [ ] PRs created from container worktrees are not abandoned on the next poll cycle - [ ] Genuinely stale branches (created days ago, many commits behind) are still detected and abandoned