hive-c0re: fix stale banner and gauge-name wording after review
The nix-store gauge comment claimed a semconv name it deliberately does not use; it now says why the name is hyperhive-scoped. Two doc pages still described the removed banner for the limits-read and knowledge-pull failures. The warning alert's comment now says pending_logins pages on purpose.
This commit is contained in:
parent
4dbcf6fa80
commit
dad495cdfa
4 changed files with 12 additions and 5 deletions
|
|
@ -66,7 +66,7 @@ pull`, so agents see the new content on their next turn.
|
|||
queues a pull on a fixed cadence as a fallback (webhook missed, c0re
|
||||
restarted between pushes). The pull is best-effort — a failure
|
||||
shows as a failed `KnowledgePull` node on the job queue, counts toward
|
||||
the knowledge-pull banner, and doesn't affect the rest of the daemon.
|
||||
the `knowledge_pull` hive warning, and doesn't affect the rest of the daemon.
|
||||
|
||||
Both paths, and the one pull at boot, queue the same `KnowledgePull` job
|
||||
node. It holds the working tree for its duration, so two pulls never run
|
||||
|
|
|
|||
|
|
@ -529,8 +529,8 @@ given.
|
|||
Every 30 seconds hive-c0re (`workers::swarm_limits`) reads the key of each
|
||||
agent it has and stores the result in `meta/swarm-resource-limits.json`. Each
|
||||
value passes the validators first. One bad
|
||||
value or a failed read leaves the file unchanged, and repeated failures raise a
|
||||
dashboard banner.
|
||||
value or a failed read leaves the file unchanged, and repeated failures raise a hive
|
||||
warning (the `hyperhive.hive.warning` metric and the `hh-hive-warning` alert).
|
||||
|
||||
A hive's queue grant reads every key of the bucket
|
||||
(`$JS.API.DIRECT.GET.KV_agent-limits.>`) and writes none. Scoping it to the
|
||||
|
|
|
|||
Loading…
Reference in a new issue