| Filename | Latest commit message | Latest commit date |
|---|---|---|
0db83c40a0
hive-forge-notify grows a second binary, hive-github-notify. The two share the notification half of the job — tolerant parse, classification, formatting, dedupe, todo delivery — and nothing else: each binary owns its host's protocol outright. Two binaries rather than one multi-source daemon, and rather than a cargo feature. A feature would unify across the workspace and cost every crate its build cache. Two binaries keep the decision in nix: forge.nix installs the forge unit, github.nix installs the github one under hyperhive.github.enable, so a hive built without that module has no github poller in its closure at all — GitHub access is separable (a tier, a policy boundary), not merely switched off. Both binaries ship from the existing derivation, so packages.nix is untouched. The split is real at the code level too, not just at the unit level. source.rs is a trait; the impls live in the binaries that use them, so neither binary links the other's protocol code and the library names no host at all. The forge-only assigned-issue rollup moves into the forge binary for the same reason: it asks the forge what is assigned to this agent, which is not a notification-protocol concern. At runtime the github unit needs a PAT at <state>/github-token, the same dashboard-provisioned token the gh wrapper and the git credential helper already use. No PAT: it logs why and exits 0, which is why the unit is Restart=on-failure and not always. Forgejo's notifications API is modelled on GitHub's, so one tolerant parse serves both — the differences (string thread ids, PullRequest vs Pull) are absorbed by lenient deserializers rather than a second parse path. Thread ids normalise to String at the parse boundary; they are only ever opaque keys. Todo keys gain a per-source prefix so the two hosts cannot collide, and the forge's is deliberately empty to keep existing forge todo keys stable across the deploy that lands this. The github loop honours the server's X-Poll-Interval, re-arming only when the server asks for a slower cadence than ours; the hint is read before the status check, because it arrives on error and empty pages too and that is exactly when it matters. Reading the notification stream needs the notifications scope on the PAT, which a token minted for push access typically lacks; the failure mode is silence, so docs/github.md says so explicitly. |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
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.