246c9471b1
The poller was a `tokio::spawn` inside the `hive-agent` serve loop. It never needed anything from that loop except a socket path, so being in-process bought nothing and cost two things: a harness restart took forge notifications down with it, and the whole forge/HTTP dependency tree was linked into the serve-loop binary. It is now `hive-forge-notify`, a per-agent daemon with its own systemd unit, a sibling of `hive-bash-daemon` and `hive-matrix-daemon`. Same contract as those two: it reaches the harness only by upserting todos on the in-agent socket, and nowhere else. The module moves verbatim (`notify.rs`) — the formatters, the activation gates, the dedupe map and all 33 tests are unchanged. Only the socket call sites are rewritten, onto a small local `todo_client` rather than the harness's. That mirrors what both sibling daemons already do, and the etiquette differs on purpose: the harness's client carries a 60s backoff schedule sized to ride out a hive-c0re restart, which its callers need because they have no retry of their own. This poller's two call sites both sit inside the 30s poll loop and both treat a failure as "leave the thread unread, try next tick", so the poll interval already is the retry; a second backoff would only stack sleeps and delay the rest of the batch. The unit is `Restart=on-failure`, not `always`. An agent with no forge account is a supported configuration and the poller reports it by logging why and exiting 0 — under `always` that clean exit would be a restart loop on every forge-less agent. `forgejo-api`, `url` and `time` drop out of `hive-agent`'s dependencies with the module. Also corrects docs that outlived the code they described: the persisted `forge_cursor` field is long gone (forge's own read-state is the durable record of what has been delivered), but `docs/persistence.md` and the `harness_state` module docs still documented it as live.
2 KiB
hive-forge-notify
Per-agent Forgejo notification poller: a long-running daemon
(hive-forge-notify) that watches the agent's unread notification list
and turns each thread into a todo the harness surfaces in
get_loose_ends. This is why an agent wakes up when someone comments
on its issue or requests its review.
When to use it
Look here when changing what a forge notification says when it
reaches an agent, or when it reaches one at all: the poll cadence, the
self-echo filter, the comment / review / new-item / state-change
wrapper formats, body-excerpt truncation, and the assigned-issue
rollup all live in notify.rs. The behaviour contract — activation
gates, filtering rules, the review-request override — is documented in
docs/forge.md, "Notification poller".
Shape
One bin, three modules:
main.rs— argument-free entry point. ReadsHIVE_AGENT_SOCKET, initialises tracing, hands off tonotify::run.notify.rs— the poller: forge client setup, the 30s loop, the formatters, mark-read, and the in-process delivery-dedupe map.todo_client.rs— one-shot JSON-line client for the harness's in-agent socket. No retry schedule of its own; see the module doc.
Why it is a separate process
It used to be a tokio::spawn inside the hive-agent serve loop. It
never needed anything from the serve loop except a socket path, and
running it in-process meant a harness restart also took forge
notifications down, and linked the whole forge/HTTP dependency tree
(forgejo-api, reqwest, time, url) into the serve-loop binary.
It is now a sibling daemon alongside hive-bash-daemon and
hive-matrix-daemon, with the same contract: it talks to the harness
over the in-agent todo socket and nowhere else.
Forge's own read-state is the durable, cross-rebuild record of what has been delivered — there is no persisted cursor to migrate or corrupt. A restarted poller re-scans only the genuinely-still-unread set, which is tiny by construction because delivery marks the thread read.