Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

[loop-generated] [bug] Gitea API assignee filter broken — returns all issues regardless of parameter #1460

New Issue
Closed
opened 2026-03-24 20:01:40 +00:00 by Timmy · 1 comment
Timmy commented 2026-03-24 20:01:40 +00:00
Owner
Copy Link

Bug: Gitea API assignee filter is broken

Problem

The Gitea 1.25.4 API endpoint GET /repos/.../issues?assignee=kimi ignores the assignee parameter entirely and returns ALL open issues.

Evidence

  • ?assignee=kimi returns 50 issues (same as unfiltered page 1)
  • ?assignee=nonexistentuser ALSO returns issues
  • ?assignee=rockachopa ALSO returns issues regardless

Impact

  • All monitoring that uses ?assignee=X to check agent workload is reading garbage data
  • Issue #1447 was filed based on this broken query (claimed Kimi had 50 issues; it had 0)
  • kimi-loop.sh and workforce-manager.py may be making incorrect decisions

Fix

Replace all ?assignee=kimi API calls with label-based filtering:

  • Use ?labels=assigned-kimi (label ID 95) instead
  • Or check assignees field on individual issues
  • Audit kimi-loop.sh, workforce-manager.py, and any dispatch scripts

Acceptance Criteria

  • All scripts that query Gitea for agent-assigned issues use working filter method
  • Verified: label-based query returns correct results
## Bug: Gitea API assignee filter is broken ### Problem The Gitea 1.25.4 API endpoint `GET /repos/.../issues?assignee=kimi` ignores the `assignee` parameter entirely and returns ALL open issues. ### Evidence - `?assignee=kimi` returns 50 issues (same as unfiltered page 1) - `?assignee=nonexistentuser` ALSO returns issues - `?assignee=rockachopa` ALSO returns issues regardless ### Impact - All monitoring that uses `?assignee=X` to check agent workload is reading garbage data - Issue #1447 was filed based on this broken query (claimed Kimi had 50 issues; it had 0) - kimi-loop.sh and workforce-manager.py may be making incorrect decisions ### Fix Replace all `?assignee=kimi` API calls with label-based filtering: - Use `?labels=assigned-kimi` (label ID 95) instead - Or check assignees field on individual issues - Audit kimi-loop.sh, workforce-manager.py, and any dispatch scripts ### Acceptance Criteria - [ ] All scripts that query Gitea for agent-assigned issues use working filter method - [ ] Verified: label-based query returns correct results
Timmy added the 222-epic label 2026-03-24 20:01:40 +00:00
Timmy commented 2026-03-24 20:27:58 +00:00
Author
Owner
Copy Link

Fixed: Replaced all broken ?assignee=X API query parameters with client-side filtering.

Root cause: Gitea 1.25.4 ignores the assignee query parameter, returning all issues regardless.

Fix: All scripts now fetch all open issues and filter by checking the assignees field in the response JSON.

Files fixed:

  • ~/.hermes/bin/ops-gitea.sh — Kimi queue display
  • ~/.hermes/bin/ops-panel.sh — Kimi, Claude, Gemini queue displays
  • ~/.hermes/bin/ops-helpers.sh — ops-queue (kimi), ops-claude-queue, ops-gemini-queue

Verification: Client-side filter correctly returns 0 issues for all agents (none currently assigned), vs the broken API returning all 30+ open issues.

Fixed: Replaced all broken `?assignee=X` API query parameters with client-side filtering. **Root cause:** Gitea 1.25.4 ignores the `assignee` query parameter, returning all issues regardless. **Fix:** All scripts now fetch all open issues and filter by checking the `assignees` field in the response JSON. **Files fixed:** - `~/.hermes/bin/ops-gitea.sh` — Kimi queue display - `~/.hermes/bin/ops-panel.sh` — Kimi, Claude, Gemini queue displays - `~/.hermes/bin/ops-helpers.sh` — ops-queue (kimi), ops-claude-queue, ops-gemini-queue **Verification:** Client-side filter correctly returns 0 issues for all agents (none currently assigned), vs the broken API returning all 30+ open issues.
Timmy closed this issue 2026-03-24 20:27:59 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label 222-epic
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok kimi manus perplexity Rockachopa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#1460
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?