[namastex888]

Tracer summary

Scheduler's attemptAgentResume increments resumeAttempts 0→1 in PG, then
shells out to genie agent resume <id> which enters resumeAgent in
agents.ts and unconditionally does registry.update({ resumeAttempts: 0 }) —
wiping the increment within the same tick. Counter was stuck at 0 forever,
which meant the exhaustion check at scheduler-daemon.ts:873
(attempts >= maxAttempts) was unreachable. Dead zombie agents were retried
every ~60s forever with no circuit breaker; genie ls showed
error (0/3 resumes) while the scheduler log showed
agent_resume_attempted resume_attempts: 1 every minute.

The line 2376 reset was designed for manual genie agent resume
invocations — a fresh retry budget on human intervention — but the scheduler
reused the same CLI entrypoint, so the manual-only reset fired on auto-resume
too.

Before / after behavior contract

Phase	Before	After
Scheduler pre-spawn increment	PG: attempts = 1	PG: attempts = 1
Scheduler shells out genie resume	CLI wipes attempts = 0	CLI with --no-reset-attempts keeps attempts = 1
Net state after one auto-resume	attempts = 0 (stuck)	attempts = 1 (persists)
After 3 failed auto-resumes	attempts = 0 (stuck; retry forever)	attempts = 3 → 'exhausted' → circuit breaker
After successful auto-resume	attempts = 0 (CLI reset)	attempts = 0 (explicit reset on success path)
Manual genie agent resume <id>	attempts = 0 (CLI reset)	attempts = 0 (CLI reset — unchanged UX)

Changes

• src/term-commands/agents.ts — resumeAgent and handleWorkerResume /
  resumeAllAgents accept an opts.resetAttempts flag, default true. All
  existing manual-path callers get the original fresh-retry-budget behavior.
• src/term-commands/agent/resume.ts — new --no-reset-attempts commander
  option plumbed through to handleWorkerResume.
• src/lib/scheduler-daemon.ts
  • defaultResumeAgent shells out with --no-reset-attempts.
  • attemptAgentResume success path: explicit
    updateAgent(id, { resumeAttempts: 0 }) so a healthy resumed agent doesn't
    carry stale 2/3 state.

Tests

Existing tests mocked resumeAgent: async () => true so they never exercised
the reset path. Four new regression tests in
src/lib/__tests__/scheduler-daemon.test.ts:

1. failed attempts accumulate the counter (pre-fix stuck at 0) — 3
   consecutive failed auto-resumes, counter progression 0→1→2→3→exhausted.
2. exhaustion check fires on re-entry with attempts=maxAttempts — the
   previously-unreachable early-exit branch is now reachable.
3. success path explicitly resets counter to 0 — verifies the new
   two-write contract (pre-spawn increment + post-success reset).
4. scheduler-owned counter: increment not wiped by resumeAgent boundary —
   direct invariant regression test for the original bug.

Two pre-existing tests updated to reflect the new two-write contract on the
success path (agentUpdates goes from length 1 to length 2).

Validation

bun run check
# 2634 pass / 0 fail / 6063 expect() calls across 138 files

Scope

Does not touch migrations, buildWorkerStatusMap, or the ls display
rendering — those were correct; only the PG column value was lying.

Related

• PR fix(scheduler): exclude NULL-state + dead-pane zombies from resume concurrency cap #1181 (fix(scheduler): exclude NULL-state + dead-pane zombies from resume concurrency cap) is merged and addresses a different symptom (the
  142-agent concurrency-cap inflation that was silently blocking every
  auto-resume attempt). This PR fixes the counter-persistence bug that fix(scheduler): exclude NULL-state + dead-pane zombies from resume concurrency cap #1181
  did not address.

Test plan

• New regression tests pass locally (4 added)
• Existing scheduler-daemon and resume tests still pass after update
• Full bun run check passes
• Dogfood post-merge: install @next, watch an error-state agent's
  counter tick 1/3 → 2/3 → 3/3, confirm agent_resume_exhausted in
  ~/.genie/logs/scheduler.log after the third attempt.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Ignore keyword(s) in the title.

⛔ Ignored keywords (3)

• WIP
• DO NOT MERGE
• wip

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: ae814978-53da-4ccf-82c0-7570db33c627

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/auto-resume-counter-persistence

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request fixes a bug in the agent resume logic where the resumeAttempts counter was being reset prematurely, leading to infinite retry loops. The changes introduce a --no-reset-attempts flag for the CLI to allow the scheduler to manage the counter lifecycle, ensuring it increments correctly and only resets upon a successful resume. Feedback was provided regarding a potential command injection vulnerability and performance issues in src/lib/scheduler-daemon.ts caused by using execSync with template literals; switching to spawnSync with an argument array is recommended.

[gemini-code-assist]

The use of execSync with a template literal for agentId introduces a potential command injection vulnerability if agentId contains shell metacharacters (such as single quotes). Additionally, execSync blocks the Node.js event loop, which can degrade the performance and responsiveness of the scheduler daemon. Using spawnSync (or ideally spawn async) with an array of arguments is safer as it avoids shell parsing issues and is generally more robust. The suggested fix uses a dynamic import to align with repository patterns for managing module dependencies.

    const { spawnSync } = await import('node:child_process');
    const result = spawnSync('genie', ['agent', 'resume', agentId, '--no-reset-attempts'], {
      encoding: 'utf-8',
      stdio: ['pipe', 'pipe', 'pipe'],
    });
    if (result.status !== 0) throw new Error('Resume failed');

References

1. Use dynamic imports (require() or import()) to break circular dependency cycles that would otherwise occur at module load time.