Timmy_Foundation/hermes-agent
16
0
Fork 0
Code Issues 57 Pull Requests 3 Actions 9 Packages Projects Releases Wiki Activity

P0: Verify Inactivity-Based Timeouts (Gateway + Cron) #115

New Issue
Open
opened 2026-04-06 14:06:53 +00:00 by Timmy · 1 comment
Timmy commented 2026-04-06 14:06:53 +00:00
Owner
Copy Link

Context

Commits fec58ad9 (gateway) and d6ef7fdf (cron) replace wall-clock timeouts with inactivity-based timeouts:

  • Gateway: agent stays alive while actively processing (even for hours), only times out on genuine inactivity
  • Cron: same pattern — HERMES_CRON_TIMEOUT=0 means unlimited
  • Diagnostic info included on timeout: last activity, idle duration, current tool, iteration count

Acceptance Criteria

  • Verify gateway timeout behavior: Start a long-running tool call (e.g., sleep 30 via terminal tool), confirm the gateway does NOT time out while the tool is actively running
  • Verify cron timeout behavior: Run a cron job that actively processes for >600s, confirm it does not timeout (wall-clock: would have been killed; inactivity-based: survives)
  • Verify diagnostic timeout message: Trigger a timeout (set HERMES_CRON_TIMEOUT=5 for testing), confirm the error includes: last activity description, idle duration, current tool, iteration count
  • Verify unlimited mode: Set HERMES_CRON_TIMEOUT=0, run a 15-minute task, confirm it completes without timeout

Why This Matters

Our burn-mode fleet (scouts, fleet auditors, CI monitors) were dying at 600s exactly, even when actively working. This was silently losing partial work. Inactivity-based timeouts mean agents work until they actually stall — not until a wall clock expires.

Hints

  • Gateway timeout: gateway/run.py — look for _check_inactivity_timeout()
  • Cron timeout: cron/scheduler.py — polling loop with agent.get_activity_summary() every 5s
  • Tests: tests/cron/test_cron_inactivity_timeout.py (289 lines, 9 test scenarios)

Parent: #111

## Context Commits `fec58ad9` (gateway) and `d6ef7fdf` (cron) replace wall-clock timeouts with inactivity-based timeouts: - Gateway: agent stays alive while actively processing (even for hours), only times out on genuine inactivity - Cron: same pattern — `HERMES_CRON_TIMEOUT=0` means unlimited - Diagnostic info included on timeout: last activity, idle duration, current tool, iteration count ## Acceptance Criteria - [ ] **Verify gateway timeout behavior**: Start a long-running tool call (e.g., `sleep 30` via terminal tool), confirm the gateway does NOT time out while the tool is actively running - [ ] **Verify cron timeout behavior**: Run a cron job that actively processes for >600s, confirm it does not timeout (wall-clock: would have been killed; inactivity-based: survives) - [ ] **Verify diagnostic timeout message**: Trigger a timeout (set `HERMES_CRON_TIMEOUT=5` for testing), confirm the error includes: last activity description, idle duration, current tool, iteration count - [ ] **Verify unlimited mode**: Set `HERMES_CRON_TIMEOUT=0`, run a 15-minute task, confirm it completes without timeout ## Why This Matters Our burn-mode fleet (scouts, fleet auditors, CI monitors) were dying at 600s exactly, even when actively working. This was silently losing partial work. Inactivity-based timeouts mean agents work until they actually stall — not until a wall clock expires. ## Hints - Gateway timeout: `gateway/run.py` — look for `_check_inactivity_timeout()` - Cron timeout: `cron/scheduler.py` — polling loop with `agent.get_activity_summary()` every 5s - Tests: `tests/cron/test_cron_inactivity_timeout.py` (289 lines, 9 test scenarios) Parent: #111
allegro commented 2026-04-06 16:30:13 +00:00
Member
Copy Link

🏷️ Automated Triage Check

Timestamp: 2026-04-06T16:30:13.327338
Agent: Allegro Heartbeat

This issue has been identified as needing triage:

Checklist

  • Clear acceptance criteria defined
  • Priority label assigned (p0-critical / p1-important / p2-backlog)
  • Size estimate added (quick-fix / day / week / epic)
  • Owner assigned
  • Related issues linked

Context

  • No comments yet — needs engagement
  • No labels — needs categorization
  • Part of automated backlog maintenance

Automated triage from Allegro 15-minute heartbeat

## 🏷️ Automated Triage Check **Timestamp:** 2026-04-06T16:30:13.327338 **Agent:** Allegro Heartbeat This issue has been identified as needing triage: ### Checklist - [ ] Clear acceptance criteria defined - [ ] Priority label assigned (p0-critical / p1-important / p2-backlog) - [ ] Size estimate added (quick-fix / day / week / epic) - [ ] Owner assigned - [ ] Related issues linked ### Context - No comments yet — needs engagement - No labels — needs categorization - Part of automated backlog maintenance --- *Automated triage from Allegro 15-minute heartbeat*
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CI
Continuous integration, runners, workflow issues
 QA
Quality assurance, testing, production audit
 assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-kimi
Task assigned to KimiClaw for processing
 blocked
Blocked by external dependency or merge conflict
 claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 duplicate
Duplicate of another issue
 epic
Epic - large feature with multiple sub-tasks
 gaming
Gaming agent capabilities
 infra
Infrastructure, VPS, DNS, deployment
 kimi-done
KimiClaw has completed this task
 kimi-in-progress
KimiClaw is actively working on this
 mcp
MCP (Model Context Protocol) tools & servers
 morrowind
Morrowind Agent gameplay & MCP integration
 needs-review
PR or issue requires reviewer sign-off before merge/close
 p0-critical
p1-important
security
Security hardening, vulnerability fixes
 stale
No activity, pending triage or closure
 velocity-engine
Auto-generated by velocity engine
 wont-fix
Closed as intentionally not fixing — explicit descope
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok groq hermes kimi manus perplexity sonnet
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/hermes-agent#115
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?