bug: issue-sync creates duplicate issues due to silent gh create failure + insufficient --limit 50

[robstiles]

Description

issue-sync-helper.sh push creates duplicate GitHub issues for the same TODO.md task. Observed in a managed private repo: 19 total duplicates across 8 task IDs, some tripled. Root cause verified from CI run logs.

Prior related issues: t1141 (#1714, search→list API) and t1142 (#1724, concurrency guard) addressed earlier duplicate vectors. The bugs below are distinct and survived those fixes.

Root Cause (verified from CI logs)

Bug 1 (Primary): gh issue create returns empty URL despite server-side creation

In _push_create_issue() (issue-sync-helper.sh line 325):

url=$(gh "${args[@]}" 2>/dev/null || echo "")
[[ -z "$url" ]] && { print_error "Failed to create issue for $task_id"; return 2; }

gh issue create creates the issue on GitHub, but returns empty stdout. The 2>/dev/null suppresses any stderr diagnostics. Code treats empty URL as full failure → no ref:GH# written to TODO.md. The pull step later finds the issue and writes the ref, but if the commit/push step fails or the user overwrites TODO.md from local, the ref is lost.

Evidence from CI push run logs (two separate runs):

• Run A push step: "Processing 10 task(s) → 0 created, 0 skipped" (all 10 "failed")
• But all 10 issues WERE created on GitHub (confirmed by creation timestamps matching exactly)
• Commit step: "No TODO.md changes to commit" — no refs persisted
• Run B push step: "Processing 29 task(s) → 0 created, 14 skipped" (15 "failed")
• But those 15 issues WERE created on GitHub

Likely cause: --label "$all_labels" includes labels like status:available,origin:worker. If label application fails after issue creation, gh may exit non-zero without printing the URL. Needs stderr capture to confirm.

Bug 2 (Amplifier): --limit 50 in gh_find_issue_by_title is insufficient

gh issue list --repo "$repo" --state "$state" --limit "$limit" \  # limit defaults to 50
    --json number,title --jq "..."

In a repo with 500+ issues, --limit 50 only covers the 50 most recent. Issues created >50 issues ago are invisible to dedup.

Evidence: --limit 50 in the affected repo returns only issues numbered #482-548. The first duplicate batch (#329-339, created 5 days earlier) is completely outside this window. When the next CI run checked for existing issues, the originals were invisible → duplicates created.

Both bugs compound: Bug 1 prevents ref write-back. Bug 2 prevents the fallback dedup check from catching the already-created issue. Together they guarantee duplicates on every subsequent push run.

Observed Pattern

• 8 task IDs affected, producing 19 total duplicate issues
• Duplicates created in 3 distinct CI push batches over 5 days
• Triple duplicates for 3 tasks, double duplicates for 5 tasks
• All created by github-actions (CI push workflow), zero from local/pulse

Reproduction Steps

1. Set up a repo with >50 open+closed issues and issue-sync.yml
2. Add tasks to TODO.md without ref:GH# and push to main
3. If gh issue create fails to return URL (intermittent), refs are not written
4. Push another TODO.md change → tasks without refs are re-processed
5. gh_find_issue_by_title --limit 50 misses the old issues → duplicates created

Recommended Fixes

Fix 1: Resilient gh issue create error handling (critical)

# In _push_create_issue(), replace line 325-329:
local url
url=$(gh "${args[@]}" 2>&1)
local gh_exit=$?
if [[ $gh_exit -ne 0 || -z "$url" || ! "$url" =~ ^https:// ]]; then
    # Issue may have been created despite error — recovery check
    sleep 1  # Brief delay for API consistency
    local recovery
    recovery=$(gh_find_issue_by_title "$repo" "${task_id}:" "all" 500)
    if [[ -n "$recovery" && "$recovery" != "null" ]]; then
        print_warning "gh create exited $gh_exit but issue found: #$recovery"
        _PUSH_CREATED_NUM="$recovery"
        return 0
    fi
    print_error "Failed to create issue for $task_id (exit $gh_exit): ${url:0:200}"
    return 2
fi

Fix 2: Increase --limit from 50 to 500

# In gh_find_issue_by_title(), change default:
local repo="$1" prefix="$2" state="${3:-all}" limit="${4:-500}"

Also update all call sites passing explicit limit. 500 covers repos up to ~1000 issues; for larger repos, consider paginated search.

Fix 3: Use cancel-in-progress: false for sync-on-push (latent risk)

The original t1142 recommended cancel-in-progress: false, but the implementation used true. While zero cancelled runs were observed, this is a latent risk — a cancelled run after issue creation but before ref write-back produces the same orphaned-issue pattern as Bug 1.

Fix 4: cmd_pull misleading success messages

cmd_pull prints print_success "Added ref:GH#..." even when add_gh_ref_to_todo silently skips (because a ref already exists). This made debugging harder. Check return value or file modification before printing success.

Factors Ruled Out

• cancel-in-progress killing runs: 0 cancelled runs in 500-run history. Not the trigger, but still a latent risk.
• Pulse/local push: No pulse scheduled in affected repo. All dupes from CI. CI-only guard at line 425 works correctly.
• GitHub search API lag: gh_find_issue_by_title already uses gh issue list (real-time API, fixed by t1141), not search. Not a factor.
• Race between concurrent runs: Concurrency group exists (t1142). Not the trigger.
• User error: Normal operation — push TODO.md to main, CI syncs. Working as designed; bugs are in framework code.

Environment

• aidevops version: 3.5.565
• OS: Ubuntu 24.04.4 LTS
• Shell: bash 5.2.21(1)-release
• gh CLI: gh version 2.89.0
• Repo: a managed private repo (548 issues at time of analysis)

Cleanup Already Done

12 duplicate issues closed and 11 tasks annotated with ref:GH# in the affected repo.

[github-actions]

Thanks for the report, @robstiles.

This issue has been queued for maintainer review. A maintainer will review it and either:

• Approve it for the development pipeline (status:available)
• Ask for more information if the report needs clarification
• Close it if it's a duplicate or out of scope

Tip: For faster, higher-quality issue reporting, use /log-issue-aidevops in your AI assistant session. It gathers diagnostics automatically and checks for duplicates.

[marcusquinn]

Dispatching triage review worker (opus-tier).

• Scope: Review bug report — issue-sync creates duplicate issues due to silent gh create failure + insufficient --limit 50
• Attempt: 1
• Direction: Assess root cause, verify reproducibility, recommend fix approach for maintainer review.

---

aidevops.sh v3.5.567 plugin for OpenCode v1.3.13 with claude-sonnet-4-6 spent 16h 16m on this as a headless worker. Overall, 1h 43m since this issue was created.

[marcusquinn]

DISPATCH_CLAIM nonce=9e2f3ba5ecd1aafa8f8ae1f78852e539 runner=marcusquinn ts=2026-04-01T21:17:07Z max_age_s=120

[marcusquinn]

Review: Approved

Issue Validation

Check	Status	Notes
Reproducible	Yes	CI logs show 0 created / 0 skipped despite issues being created on GitHub — pattern is deterministic given the label-failure trigger
Not duplicate	Yes	#1714 (search→list API) and #1724 (concurrency guard) are closed and address different vectors. This is a new compound failure mode.
Actual bug	Yes	gh issue create creates the issue server-side but exits non-zero (label application failure) — 2>/dev/null suppresses the diagnostic, empty URL treated as full failure, no ref written
In scope	Yes	Core issue-sync reliability — directly impacts all users with >50 issues or intermittent label failures

Root Cause: Two independent bugs compound. Bug 1: gh issue create with --label can exit non-zero after server-side creation (label application failure), 2>/dev/null hides the error, empty URL → no ref write-back. Bug 2: --limit 50 in gh_find_issue_by_title makes the dedup check blind to issues created more than 50 issues ago. Together: issue created but not tracked → next run can't find it → duplicate created. Repeats on every subsequent push.

Code verified against .agents/scripts/issue-sync-helper.sh:

• Line 325: url=$(gh "${args[@]}" 2>/dev/null || echo "") — confirmed
• Line 121: local repo="$1" prefix="$2" state="${3:-all}" limit="${4:-50}" — confirmed
• Lines 316, 347, 484, 610, 732: all call sites pass explicit 50 — confirmed

Solution Evaluation

Criterion	Assessment	Notes
Simplicity	Good	Fix 1 adds ~8 lines; Fix 2 is a one-line default change + call-site updates
Correctness	Good	Recovery check after non-zero exit handles the orphaned-issue case; 500 limit covers repos up to ~1000 issues
Completeness	Good	Fix 3 (cancel-in-progress) and Fix 4 (misleading pull success messages) are lower priority but valid hardening
Consistency	Good	Recovery pattern matches existing race-condition guard at line 316

One adjustment to Fix 1: The proposed recovery uses sleep 1 before the API call. This is fine for correctness but adds latency in the hot path. Recommend making the sleep conditional on $gh_exit -ne 0 only (already the case in the proposed code — no change needed, just noting it's acceptable).

Fix 3 note: The issue correctly identifies cancel-in-progress: true as a latent risk. The t1142 recommendation was false; the implementation used true. Worth correcting in the same PR.

Scope & Recommendation

• Scope creep: Low — all four fixes are tightly scoped to _push_create_issue and gh_find_issue_by_title
• Complexity: Medium (sonnet)
• Decision: APPROVE — implement all four fixes in a single PR
• Labels: bug, tier:simple (Fix 2 is trivial; Fix 1 adds ~8 lines of existing-pattern code)
• Implementation guidance:
  1. Fix _push_create_issue (line 325): capture stderr, check exit code, run recovery gh_find_issue_by_title with limit 500 on non-zero exit
  2. Change gh_find_issue_by_title default limit from 50 to 500 (line 121)
  3. Update all explicit 50 call sites (lines 316, 347, 484, 610, 732) to 500
  4. Fix cancel-in-progress in the issue-sync GitHub Action workflow to false
  5. Fix cmd_pull success message to check return value before printing (Fix 4)
  6. Add a test case: simulate gh issue create returning empty URL with non-zero exit, verify recovery finds the issue and writes the ref

---

aidevops.sh v3.5.570 plugin for OpenCode v1.3.13 with claude-sonnet-4-6 spent 2h 24m and 30,940 tokens on this with the user in an interactive session. Overall, 2h 32m since this issue was created.

[marcusquinn]

Dispatching worker.

• Branch: N/A (triage review)
• Scope: Opus-tier triage review of bug: issue-sync duplicate issues
• Attempt: 1 of 1
• Direction: /review-issue-pr — assess root cause, propose fix

---

aidevops.sh v3.5.570 plugin for OpenCode v1.3.13 with claude-sonnet-4-6 spent 17h 9m on this as a headless worker.

[alex-solovyev]

Dispatching triage review worker.

• Scope: Review and assess issue for maintainer decision
• Attempt: 1 of 3
• Direction: Analyze the bug report about issue-sync duplicate creation, verify the claim, and provide a triage recommendation

---

aidevops.sh v3.5.570 plugin for OpenCode v1.3.13 with claude-opus-4-6 spent 16h 59m on this as a headless worker. Overall, 2h 36m since this issue was created.

[alex-solovyev]

Review: Approved

Issue Validation

Check	Status	Notes
Reproducible	Yes	Code path is deterministic: gh issue create with failing label application → non-zero exit → 2>/dev/null hides diagnostic → empty URL → no ref write-back. Pattern repeats on every subsequent push.
Not duplicate	Yes	#1714 (t1141: search→list API) and #1724 (t1142: concurrency guard) are closed and address different vectors. This is a new compound failure mode surviving both fixes.
Actual bug	Yes	Two independent bugs confirmed in code. See root cause below.
In scope	Yes	Core issue-sync reliability — affects all users with >50 issues or intermittent label failures.

Root Cause (verified against current code)

Bug 1 — Silent gh issue create failure (critical): _push_create_issue() at issue-sync-helper.sh:325:

url=$(gh "${args[@]}" 2>/dev/null || echo "")

2>/dev/null suppresses all stderr. If gh issue create creates the issue server-side but exits non-zero (e.g., label application failure with --label "$all_labels" where $all_labels contains comma-separated labels like status:available,origin:worker), the URL is empty, the function returns error at line 326-328, and no ref:GH# is written to TODO.md. The issue exists on GitHub but is invisible to the sync system. Every subsequent push run re-processes the task and creates a duplicate.

Bug 2 — --limit 50 insufficient for dedup (amplifier): gh_find_issue_by_title() at issue-sync-helper.sh:121:

local repo="$1" prefix="$2" state="${3:-all}" limit="${4:-50}"

All 5 call sites (lines 316, 347, 484, 610, 732) pass explicit 50. In repos with >50 issues, the dedup check only sees the 50 most recent. Issues created >50 issues ago are invisible → duplicates created when Bug 1 prevents ref write-back.

Compound effect: Bug 1 prevents the primary dedup mechanism (ref:GH# in TODO.md). Bug 2 prevents the fallback dedup mechanism (title-prefix search). Together they guarantee duplicates on every subsequent push run for affected tasks.

Bug 3 — cancel-in-progress: true (latent risk): issue-sync.yml:38 uses cancel-in-progress: true despite t1142 recommending false. A cancelled run after issue creation but before ref write-back produces the same orphaned-issue pattern. No cancelled runs observed in the reporter's case, but this is a ticking time bomb.

Bug 4 — Misleading cmd_pull success messages: issue-sync-helper.sh:554 prints print_success "Added ref:GH#$num to $tid" after calling add_gh_ref_to_todo, which silently returns 0 when the ref already exists (issue-sync-lib.sh:1069). The success message prints regardless of whether any change was made. Minor but complicates debugging.

Solution Evaluation

Criterion	Assessment	Notes
Simplicity	Good	Fix 1 adds ~8 lines of recovery logic using existing gh_find_issue_by_title. Fix 2 is a default-value change + 5 call-site updates. Fix 3 is a one-line YAML change. Fix 4 is a return-value check.
Correctness	Good	Recovery check after non-zero exit handles the orphaned-issue case. 500 limit covers repos up to ~1000 issues. Both fixes address root causes, not symptoms.
Completeness	Good	All four fixes are valid. Fix 1 also needs stderr capture (not just suppression) for diagnostics.
Consistency	Good	Recovery pattern is consistent with the existing race-condition guard at line 314-320.

One refinement to Fix 1: The proposed fix should also log the captured stderr for diagnostics rather than just checking exit code. Replace 2>/dev/null with stderr capture so future failures are diagnosable:

local stderr_file
stderr_file=$(mktemp)
url=$(gh "${args[@]}" 2>"$stderr_file") || true
local gh_exit=$?
local stderr_content
stderr_content=$(cat "$stderr_file" 2>/dev/null || true)
rm -f "$stderr_file"

This preserves the diagnostic information that 2>/dev/null currently destroys.

Scope & Recommendation

• Scope creep: Low — all four fixes are tightly scoped to _push_create_issue, gh_find_issue_by_title, issue-sync.yml, and cmd_pull
• Complexity: Medium (sonnet-tier) — straightforward code changes with clear patterns
• Decision: APPROVE — implement all four fixes in a single PR
• Labels: bug, tier:simple
• Implementation guidance:
  1. Fix _push_create_issue (line 325): capture stderr, check exit code, run recovery gh_find_issue_by_title with limit 500 on non-zero exit or empty URL
  2. Change gh_find_issue_by_title default limit from 50 to 500 (line 121)
  3. Update all 5 explicit 50 call sites (lines 316, 347, 484, 610, 732) to 500
  4. Fix cancel-in-progress in issue-sync.yml sync-on-push job from true to false (line 38)
  5. Fix cmd_pull to check add_gh_ref_to_todo return value or file modification before printing success
  6. Add test: simulate gh issue create returning empty URL with non-zero exit, verify recovery finds the issue and writes the ref

---

aidevops.sh v3.5.570 plugin for OpenCode v1.3.13 with claude-opus-4-6 spent 1d and 390 tokens on this with the user in an interactive session. Overall, 2h 37m since this issue was created.

[marcusquinn]

Dispatching worker (deterministic).

• Worker PID: 65215
• Model: anthropic/claude-sonnet-4-6
• Runner: marcusquinn
• Issue: bug: issue-sync creates duplicate issues due to silent gh create failure + insufficient --limit 50 #15234