Watch
0
0
Fork
You've already forked hyperhive
0
hyperhive/swarm-review-classifier
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas a6935e57c3 swarm-queue-client: re-read a held OIDC client secret when the IdP refuses it
hive-c0re (`hive-<name>`), swarm-controller and swarm-review-classifier
read their queue client secret from the store once and held it as
`ClientSecret::Value` for the life of the process. After authelia
re-minted a secret and swarm-secret-publish stored the new one, every
later token mint presented the old value and was refused until the
daemon restarted.

`ClientSecret::Stored` replaces `Value`: a `StoredSecret` holds the
secret in memory with a caller-supplied read callback, so the crate
takes no store dependency. When the token endpoint answers 400 or 401,
`mint_token` (and its blocking sibling, used by the controller's OTLP
exporters) re-reads it and, if the store holds a different secret,
mints once more with it. One re-read runs at a time and is spawned so
it outlives a caller that gives up. A re-read that fails or finds the
refused value delays the next one, 5 s doubling to 5 min, so a secret
that stays wrong costs one store read per delay. Logs name the client
id and never the secret.

swarm-nats-auth's `oidc_secret` was the template; its re-read machinery
now sits on `StoredSecret`, so the tree has one copy. The responder
gains the same re-read backoff.

The controller keeps its `IDENTITY` OnceLock: it now holds a
`QueueConfig` whose secret is re-read, and the lazily built vcs-metrics
exporter reads the identity from it.

agent_renewal.rs's module doc said a re-minted agent queue secret only
reaches the agent at its next start; hive-agent reads the store on every
connection attempt after its first, so the doc now says that.

Part of #5017 (slice Q).
2026-10-13 19:16:04 +02:00
..
src swarm-queue-client: re-read a held OIDC client secret when the IdP refuses it 2026-10-13 19:16:04 +02:00
tests swarm-review-classifier: claude's environment is an allowlist, not the daemon's 2026-10-12 13:11:21 +02:00
Cargo.toml swarm-review-classifier: answer a try-out with one claude run per classification 2026-10-12 13:11:21 +02:00
README.md nix: hand the review classifier its store leaf as an nspawn credential 2026-10-12 13:11:21 +02:00

swarm-review-classifier

The review classifier's try-out service, in the swarm-review-classifier container on the host that sets deploy.review-classifier.enable. The design is docs/swarm/review-classifier.md.

swarm-controller reads a PR (its head commit, its commits and its diff) and sends it, with the operator's classifications, as a request on the queue. This service asks a small model one classification at a time and answers with the result table and the overall verdict. It writes nothing to the forge and holds no forge credential.

What a run is

  • The shared context first: a system prompt, the PR's commits with their full messages, and the diff with lockfiles collapsed as hive-forge diff does. Every classification's prompt starts with the same bytes.
  • One claude --print per classification, with no session, no tools (--tools ""), no MCP server, its own empty directory and ANTHROPIC_API_KEY in its environment only.
  • An answer is a JSON object with a verdict, a certainty and a reason of at most 500 characters. A failed run, a timeout or an answer that doesn't validate leaves that row without a verdict, and it doesn't count.
  • A run with no API key, or with no classification answered, fails as a whole: the caller sees an error, never a verdict.

Credentials

The container holds one credential: its own store certificate, which nspawn hands in at start without a copy on disk. With it the service reads its queue client secret at start and the API key at every run, so a key written or removed in the store takes effect on the next run. Its store role reads exactly those two paths.