Issue Fixer Pipeline — Known Issues and Fixes Applied #34

Closed
opened 2026-05-12 19:37:59 +00:00 by Mark · 1 comment
Owner

Issue: no_agent 120s Timeout

Symptom

The script would be killed after 120 seconds by the cron scheduler in no_agent mode. The GSD pipeline and hermes chat -q calls can take longer than 120s to complete.

Fix Applied

Switched both issue-fixer-autorun and feature-triage from no_agent=true to agent-mode (LLM-driven). In agent-mode, the script runs under the subprocess timeout (configurable, typically 600s) instead of the scheduler's hard 120s no_agent cap. The agent LLM then processes the script output for delivery.

Files Changed

  • Cron job config: issue-fixer-autorun (no_agent removed)
  • Cron job config: feature-triage (no_agent removed)

Issue: Feature Requests Blocked in Silence

Symptom

The original next-issue.sh silently labeled feature-request issues and dumped them in a skip pile with no visibility or decision point. All ~165 feature requests across 24 repos were auto-skipped with no triage.

Fix Applied

Created the feature-triage cron job and label bridge system. Feature requests now get:

  1. Assessed by deepseek for scope, risk, and spec alignment
  2. Auto-approved (small+low+aligned) -> triage-approved label -> enters fixer pipeline
  3. Deferred 24h (medium/partial) -> re-triaged later
  4. Needs decision (large/high/misaligned) -> blocked:needs-decision label + assessment comment on the issue

Files Created

  • ~/.hermes/scripts/feature-triage.py
  • ~/.hermes/scripts/feature-triage-state.json

Issue: exfil_curl Threat Pattern

Symptom

Cron job failed because the prompt text matched the exfil_curl threat pattern (a curl command with a token in it).

Fix Applied

Rewrote the cron prompt to avoid including raw curl commands with tokens. The script handles API calls internally.


Issue: Gate Pipeline Blocks (pre-dispatch gate missing)

Symptom

GSD pipeline blocks at the pre-dispatch gate because implementation scripts don't call the pre-dispatch.sh gate script.

Status

Still a known friction point. The gates must be called explicitly by the implementation phase. Current pipeline expects the implement step to run something like: bash ~/Projects/gsd-self/.gsd/gates/pre-dispatch.sh


Issue: Duplicate state when label_issue fails

Symptom

If the Forgejo label_issue API call fails (e.g., label already exists), the state file may still record the issue as visited, causing it to be skipped permanently.

Status

Minor issue. The state append happens regardless of API success.

## Issue: no_agent 120s Timeout ### Symptom The script would be killed after 120 seconds by the cron scheduler in no_agent mode. The GSD pipeline and hermes chat -q calls can take longer than 120s to complete. ### Fix Applied Switched both issue-fixer-autorun and feature-triage from no_agent=true to agent-mode (LLM-driven). In agent-mode, the script runs under the subprocess timeout (configurable, typically 600s) instead of the scheduler's hard 120s no_agent cap. The agent LLM then processes the script output for delivery. ### Files Changed - Cron job config: issue-fixer-autorun (no_agent removed) - Cron job config: feature-triage (no_agent removed) --- ## Issue: Feature Requests Blocked in Silence ### Symptom The original next-issue.sh silently labeled feature-request issues and dumped them in a skip pile with no visibility or decision point. All ~165 feature requests across 24 repos were auto-skipped with no triage. ### Fix Applied Created the feature-triage cron job and label bridge system. Feature requests now get: 1. Assessed by deepseek for scope, risk, and spec alignment 2. Auto-approved (small+low+aligned) -> triage-approved label -> enters fixer pipeline 3. Deferred 24h (medium/partial) -> re-triaged later 4. Needs decision (large/high/misaligned) -> blocked:needs-decision label + assessment comment on the issue ### Files Created - ~/.hermes/scripts/feature-triage.py - ~/.hermes/scripts/feature-triage-state.json --- ## Issue: exfil_curl Threat Pattern ### Symptom Cron job failed because the prompt text matched the exfil_curl threat pattern (a curl command with a token in it). ### Fix Applied Rewrote the cron prompt to avoid including raw curl commands with tokens. The script handles API calls internally. --- ## Issue: Gate Pipeline Blocks (pre-dispatch gate missing) ### Symptom GSD pipeline blocks at the pre-dispatch gate because implementation scripts don't call the pre-dispatch.sh gate script. ### Status Still a known friction point. The gates must be called explicitly by the implementation phase. Current pipeline expects the implement step to run something like: bash ~/Projects/gsd-self/.gsd/gates/pre-dispatch.sh --- ## Issue: Duplicate state when label_issue fails ### Symptom If the Forgejo label_issue API call fails (e.g., label already exists), the state file may still record the issue as visited, causing it to be skipped permanently. ### Status Minor issue. The state append happens regardless of API success.
Mark 2026-05-23 03:43:51 +00:00
Author
Owner

Fix Applied: Duplicate state when label_issue fails

Repository: Mark/hermes-scripts
Commit: 8de3852

Changes

  1. label_issue() returns success status — now returns True on success, False on failure (checks curl returncode)
  2. Visited marking gated on API success — moved from before the API call to after it, only marks visited if label_issue() succeeds
  3. Failure handling — if the API call fails, the issue is NOT marked visited and logs a warning. The next triage cycle will retry it.

What was broken

When label_issue() failed (network error, rate limit, label already exists), the issue was already marked as visited in the state file, causing it to be permanently skipped.

## Fix Applied: Duplicate state when label_issue fails **Repository:** Mark/hermes-scripts **Commit:** 8de3852 ### Changes 1. **label_issue() returns success status** — now returns True on success, False on failure (checks curl returncode) 2. **Visited marking gated on API success** — moved from before the API call to after it, only marks visited if label_issue() succeeds 3. **Failure handling** — if the API call fails, the issue is NOT marked visited and logs a warning. The next triage cycle will retry it. ### What was broken When label_issue() failed (network error, rate limit, label already exists), the issue was already marked as visited in the state file, causing it to be permanently skipped.
Sign in to join this conversation.
No description provided.