Repository navigation
ci(flake-inputs-update): failure-issue lookup caps at the 100 newest open issues — this repo already has 143 open, so the one tracking issue will be missed, duplicated, and never closed #913
Description
Finding
The flake-inputs-update workflow added in PR #907 (merged; the file is at current main HEAD 3645dda22adc) tracks all of its failures in ONE issue, found by exact title. The lookup that finds it is capped at 100 open issues — and this repo already has more open issues than that, so the single-tracking-issue design breaks in production:
.github/workflows/flake-inputs-update.yml:61("Find an open failure issue" step):
gh issue list --state open --limit 100 --json number,titlefollowed by ajqexact-title match forchore(deps): automated openchamber+opencode input update failing.gh issue listreturns newest-created first and stops at the limit. Verified 2026-10-25 by two methods: the search API reports 143 open issues in developing-today/code, andgh issue list --state open --limit 200returns 143. The cap is already exceeded before the workflow has ever opened its failure issue.- This repo files new issues continuously, so a failure issue that is found when fresh will fall out of the newest-100 window quickly (edits do not change creation order).
What goes wrong when the lookup misses
All of these are in the same workflow file and key off the step's number output:
- The "Record the failure" step sees an empty
EXISTING_NUMBERand runsgh issue create— a duplicate tracking issue, contradicting the workflow's stated "one issue per workflow, never a new one" contract (header comment and PR ci: scheduled flake-inputs-update workflow (openchamber + opencode) #907 body). - The attempt count and "First failure" timestamp are parsed from the old issue's body only when it is found, so the duplicate restarts at
Attempts: 1with a fresh first-failure time and an empty failure history. - On the next success, both close paths (the "Publish and merge the update" step and the "Close the failure issue (pins already current)" step) close only the found number, and the update PR only carries
Fixes #<n>for the found number — the original failure issue is never commented on or closed and stays open forever.
Why it matters
The workflow merges flake-input updates on its own schedule; its failure issue is the only signal when updates start failing. Duplicated/reset tracking issues and a never-closed original make failures easy to miss and the failure history unreliable — exactly what the one-issue design in PR #907 was meant to prevent.
Evidence
- PR: ci: scheduled flake-inputs-update workflow (openchamber + opencode) #907 "ci: scheduled flake-inputs-update workflow (openchamber + opencode)", head
9e95477519, merged as3645dda22adc(current main HEAD at review time). - File:
.github/workflows/flake-inputs-update.ymlline 61 (lookup), plus the create/edit and close logic in the failure-recording, publish, and pins-current steps of the same file. - Live counts, 2026-10-25:
gh api "search/issues?q=repo:developing-today/code+type:issue+state:open"→total_count143;gh issue list --state open --limit 200→ 143 issues.
Acceptance criteria
- The failure-issue lookup no longer depends on the issue being among the newest N open issues: e.g. look it up with a title search (
gh issue list --search/ the search API), a dedicated label, or a fully paginated list. - With >100 open issues and an existing failure issue older than the 100 newest, a failing run edits that same issue (attempt count increments, first-failure time and history preserved) instead of creating a new one.
- A subsequent successful run closes that same pre-existing issue on both success paths (update PR merged, and pins-already-current).
- Verification covers the >100-open-issues case explicitly (stubbed
ghoutput or a documented live check), not only the fresh-repo case.
Found by the pr-diff-review job reviewing PR #907.
Activity
developing-today commentedon Oct 25, 2026
CODE-152
dezren39 commentedon Oct 26, 2026
Intake review
Still live: verified this run — the repo is at 143+ open issues and the
flake-inputs-updateworkflow's failure-issue lookup at .github/workflows/flake-inputs-update.yml:61 still caps at--limit 100with an exact-titlejqmatch; the only open PR touching this workflow is #918, which fixes the excerpt (#917), not the lookup.Related: #917 / PR #918 (sibling defect in the same workflow — worth fixing in the same pass over the file), PR #907 (the workflow's origin, where this was found), #603 (a different update script — not the same tracking issue).
Notes / risks: the failure mode is silent and self-compounding: the first miss creates a duplicate tracking issue, resets the attempt count and first-failure history, and orphans the original so no success path ever closes it. It only triggers once a real failure issue ages out of the newest-100 window, which is precisely when the history matters most.
Suggested approach: per the body's acceptance criteria — find the tracking issue by search API or a dedicated label (or paginate fully), and verify explicitly against the >100-open-issues case with a stubbed
gh.🤖 Agent note · filed
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
11 remaining items
dezren39 commentedon Nov 1, 2026
🤖 Agent note · parked
bash -n, andgit diff --checkpass; CodeRabbit is skipped/NEUTRAL and Codex review is still running, so no merge was attempted.dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done