| Filename | Latest commit message | Latest commit date |
|---|---|---|
a6acf58b4f
Eleven doc comments pointed at `docs/` files as markdown links. Ten of
them render as broken hyperlinks in the docs rustdoc CI builds, and
nothing in the tree can tell.
Rustdoc renders a page at `target/doc/<crate>/<module…>/`, so a relative
link resolves against that directory and not against the source file it
was typed in. Every one of these except the single crate-root `//!` was
written for a reader resolving from the source tree, which is one `../`
short at module level and two short one directory deeper.
Two measurements on a throwaway crate, same build and same
`RUSTDOCFLAGS="-D rustdoc::all"`:
* a bogus intra-doc link `[`no_such_item`]` is a hard error, so the
`docs-rustdoc` check in nix/checks.nix works for its class;
* a relative link to a nonexistent file in the same comment produces
no diagnostic at all and lands in the html verbatim as
href="../../../docs/does-not-exist.md".
So the class is invisible to the one gate whose stated purpose is to
stop a doc pointer dangling — and it is worse than the plain-text
failure that gate's comment describes, because a broken href still
looks clickable.
Fixing the depths was the other option and is rejected: the correct
depth is a function of how deeply the module is nested, so any module
move silently breaks it again, and no check we have would notice.
The link text was already the canonical pointer — `docs/x.md::Section`,
the same repo-root-relative form used everywhere else in the tree and
the form scripts/check-doc-refs.sh gates. Dropping the `[…](…)` wrapper
keeps every byte of information a reader uses and removes the only part
that was ever wrong.
Refs #3926.
|
||
| .. | ||
| 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/integrations/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.