← graph

dispatcher-poll-lower

Dispatcher poll: lower default + add kick signal on state changes

Metadata

Statusdone
Assignedagent-898
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-28T00:54:48.582438629+00:00
Started2026-04-28T00:55:29.876241321+00:00
Completed2026-04-28T01:23:43.522706601+00:00
Tagseval-scheduled
Eval score0.78
└ blocking impact0.80
└ completeness0.80
└ constraint fidelity0.70
└ coordination overhead0.80
└ correctness0.75
└ downstream usability0.75
└ efficiency0.75
└ intent fidelity0.71
└ style adherence0.80

Description

Description

Source: /home/erik/workgraph/bug-dispatcher-poll-interval-too-slow.md (filed 2026-04-27 from a ~/poietic session). After this task lands, delete that markdown file.

Current dispatcher polls every 60s (was 30s when bug was filed; got worse). User decides 'is this thing on?' at ~3s and loses confidence at ~10s. Every wg publish / wg unclaim / wg service resume currently produces 0–60s of dead-air before agents spawn. There is no correctness reason for the long interval — ready-task scan + spawn is cheap, idle ticks are near-free.

Two-part fix (both, not either-or)

Part 1 — lower the default poll_interval to 5s. Sweet spot from the bug report: fast enough that newly-added tasks visibly start working 'right away', slow enough that idle polling stays trivial. Locate where the default is shipped (wg config init, wg setup, or hard-coded fallback) and change ALL of them. Existing user configs are out of scope — only the default for new installs.

Part 2 — explicit kick signal. Add an IPC kick (e.g. IpcRequest::KickDispatcher or similar) and call it from:

  • wg publish (after state mutation succeeds)
  • wg unclaim (after state mutation succeeds)
  • wg service resume (right after resuming)
  • wg add when the task is published immediately (not draft)

Kick = 'wake up and run one tick now, regardless of timer'. The periodic poll stays as the safety net for missed wakeups. If daemon is offline, kick is a no-op (don't error).

Out of scope (do NOT do)

  • Full event-driven rewrite (Option B from the bug report). Stays as a separate task if we want it later.
  • Changing existing user configs / migration. Just the default.
  • The reset-doesn't-unclaim bug — that's a separate task.

Validation

  • Failing test first: spin up a daemon at the new 5s default, wg add + publish a task, assert agent spawns within 2s (uses kick path) — NOT 5s (which would be the polled path)
  • Failing test first: with daemon running, wg unclaim <task> triggers a kick → next tick happens within 1s instead of waiting for the next 5s boundary
  • Failing test: kick when daemon is offline is a no-op (no error to user)
  • Default poll_interval is 5 (or whatever was chosen) in: wg config init output, wg setup output, and the hard-coded fallback when no config exists
  • cargo build + cargo test pass with no regressions
  • Live smoke: fresh wg init, wg service start, wg add something, time-to-spawn observed <2s
  • Live smoke: wg status shows the new poll value (poll=5s not poll=60s)
  • Delete /home/erik/workgraph/bug-dispatcher-poll-interval-too-slow.md after merge (it's untracked, just rm)

Depends on

Required by

Log