2.7 KiB
| id | type | title | tags | importance | confidence | created | updated | relations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| c1a50fb8-9084-439d-a156-872bedb9013b | fix | Fix: Issue-poller infinite loop — PRs returned as issues by gitea-mcp list_repo_issues |
|
0.9 | 0.8 | 2026-03-03T21:24:58.158715+00:00 | 2026-03-03T21:25:56.958675+00:00 |
|
Issue-Poller Infinite Loop Bug
Project
claude-scheduled / issue-poller automation
Problem
The issue-poller had an infinite loop where PRs created by the worker were picked up as new "issues" on subsequent poll cycles, causing a chain of recursive PR creation:
Issue #25 → PR #35 → PR #36 → PR #37 → PR #39
Each new PR was "fixing" the previous one as if it were an open issue.
Root Cause
The mcp__gitea-mcp__list_repo_issues MCP tool does NOT expose a type parameter. The underlying Gitea REST API supports ?type=issues to filter server-side, but the MCP wrapper silently ignores it. As a result, PRs and issues are returned together, and the poller treated every open PR as an unhandled issue.
Fix
Replaced the Haiku+MCP call for listing issues with a direct curl call to the Gitea REST API:
curl -s -H "Authorization: token $GITEA_TOKEN" \
"https://git.manticorum.com/api/v1/repos/{owner}/{repo}/issues?state=open&type=issues"
The ?type=issues parameter filters PRs server-side, returning only true issues.
Alternative (MCP path)
If forced to use MCP, filter client-side by checking item["pull_request"] — it is null for real issues and a dict for PRs.
Affected Repo
paper-dynasty-database on git.manticorum.com