hyperhive/hive-forge-notify
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas be3411e180 feat(#3245): gate rustdoc in nix flake check, and clear the workspace
Nothing in the gate read doc-comments: clippy doesn't check intra-doc
links, cargo test doesn't, and no check built docs. So a [`Foo`] pointing
at a renamed, moved or deleted item rendered as plain text and had no
discoverer but a human happening to read the comment.

That matters here more than in most repos, because the convention is to
put a thing's authoritative description in one doc-comment and point at
it from everywhere else -- the design leans on the pointers being real,
and a dangling link is worse than no link since it names something and
sends the reader looking.

Adds `docs-rustdoc` to nix/checks.nix: craneLib.cargoDoc over
--workspace --no-deps --document-private-items, denying six rustdoc
lints. Listed explicitly rather than -D warnings so a new lint appearing
upstream cannot red the build on a class nobody has triaged.

--document-private-items is load-bearing rather than thoroughness for
its own sake: most of this workspace's doc-comments live on private
items and //! module headers, so without it rustdoc checks a small
fraction of the links and the gate sits green while the rot continues.

Then fixes every error it reports, 40 to 0 across nine crates. The
classes differ and so do the fixes:

- public item, wrong scope -> qualify. Node and Node::parent are both
  public; the link failed only because scheduler.rs does not import
  Node. Six sites become [`crate::Node::parent`].
- private item -> downgrade to backticks. Nothing was made public to
  satisfy a lint; changing API surface to appease a doc check would be
  the tail wagging the dog.
- genuinely dead -> [`JobBuilder::insert_into`] names a method that does
  not exist. Insertion is Scheduler::insert_job.
- prose that looks like markup -> argv[0] parsed as a link, and
  <args>/<hex>/<name> parsed as HTML tags.

Note for future fixes: pub(crate) resolves in an intra-doc link, a plain
private fn in a binary crate does not (wait_for_nodes resolved,
connect_hint did not, same crate, same shape).

The check does not ride the clippy/test artifact cache. It takes
cargoArtifacts, but rustdoc needs its own flavour of dependency
metadata, which cargo build does not produce, so a --no-deps docs build
still compiles dependencies it never documents. Measured at 6m47s cold;
that reasoning is recorded in the check's own comment so the next reader
does not re-derive it.

Verified by running the check's exact command against the pre-cleanup
tree first: 40 errors, build failed. A gate that cannot fail is not
evidence, and building it before the cleanup makes that proof free.
2026-08-14 02:30:55 +02:00
..
src feat(#3245): gate rustdoc in nix flake check, and clear the workspace 2026-08-14 02:30:55 +02:00
Cargo.toml refactor(sock): one socket client, retry as a policy value 2026-07-26 22:44:48 +02:00
README.md refactor(hive-agent): split the forge notification poller into its own crate 2026-07-26 21:30:29 +02:00

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. Reads HIVE_AGENT_SOCKET, initialises tracing, hands off to notify::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.