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

Merged

dev-qwen merged 1 commit from fix/issue-248 into main

2026-04-05 18:54:34 +00:00

dev-qwen commented

2026-04-05 18:50:17 +00:00

Collaborator

Fixes #248

Changes

Fixes #248 ## Changes

dev-qwen added 1 commit 2026-04-05 18:50:17 +00:00

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

ci/woodpecker/push/ci Pipeline was successful

Details

ci/woodpecker/pr/ci Pipeline was successful

Details

05022740ac

review-bot commented

2026-04-05 18:52:51 +00:00

Collaborator

AI Review

Summary

Two-part fix for #248 where fresh PRs were incorrectly abandoned because stale branch checks ran against unfetched refs.

Analysis

Change 1 — git fetch origin --prune before stale checks (line 375)

Correctly placed after the PID lockfile guard and before any git rev-list calls. Ensures origin/<branch> refs exist locally before the staleness computation. 2>/dev/null || true is the right idiom here — a fetch failure (e.g. network blip) should not abort the poll cycle.

Change 2 — fallback echo "0" instead of echo "999" (lines 436, 688)

When git rev-list --count fails (branch ref not present), the old fallback of 999 treated the PR as stale and closed it — a false positive that is exactly the bug described in #248. Returning 0 instead means "we cannot confirm staleness, so don't abandon" which is the correct fail-safe direction.

The two changes work together: the fetch covers the normal case (ref just needs to be downloaded), and the 0 fallback covers any residual edge where the ref still isn't available after fetch (e.g. race, network error). Both changes are applied consistently at both call sites (orphan check and backlog check).

Verdict

Logic is sound, placement is correct, and the fix is minimal with no side effects.

Verdict

APPROVE — Fetch-before-check + safe fallback correctly fixes false-positive stale detection for fresh PRs

Reviewed at 0502274 | AGENTS.md

## AI Review  ### Summary Two-part fix for #248 where fresh PRs were incorrectly abandoned because stale branch checks ran against unfetched refs. ### Analysis **Change 1 — `git fetch origin --prune` before stale checks (line 375)** Correctly placed after the PID lockfile guard and before any `git rev-list` calls. Ensures `origin/<branch>` refs exist locally before the staleness computation. `2>/dev/null || true` is the right idiom here — a fetch failure (e.g. network blip) should not abort the poll cycle. **Change 2 — fallback `echo "0"` instead of `echo "999"` (lines 436, 688)** When `git rev-list --count` fails (branch ref not present), the old fallback of `999` treated the PR as stale and closed it — a false positive that is exactly the bug described in #248. Returning `0` instead means "we cannot confirm staleness, so don't abandon" which is the correct fail-safe direction. The two changes work together: the fetch covers the normal case (ref just needs to be downloaded), and the `0` fallback covers any residual edge where the ref still isn't available after fetch (e.g. race, network error). Both changes are applied consistently at both call sites (orphan check and backlog check). ### Verdict Logic is sound, placement is correct, and the fix is minimal with no side effects. ### Verdict **APPROVE** — Fetch-before-check + safe fallback correctly fixes false-positive stale detection for fresh PRs --- *Reviewed at `0502274` | [AGENTS.md](AGENTS.md)*

review-bot approved these changes 2026-04-05 18:52:51 +00:00

review-bot left a comment

Collaborator

AI Review: APPROVE — Fetch-before-check + safe fallback correctly fixes false-positive stale detection for fresh PRs

AI Review: **APPROVE** — Fetch-before-check + safe fallback correctly fixes false-positive stale detection for fresh PRs