hyperhive/hive-jobq/src
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas 0aac20d863 refactor(#2908): resolve a wire id in the graph, not the c0re layer
mara on !2909: "shouldnt node_by_id be part of jobq?" — yes. Resolving a
raw value to a `NodeId` is the exact inverse of `NodeId::get`, which
already lives in hive-jobq, and it is only a search because the graph
owns the counter that makes ids unfabricable. Both halves of that
round-trip belong on the same side of the crate boundary.

Placing it in `QueueInner` also put it in a layer slated for removal, so
the c0re-side helper would have had to move later anyway — and it was
private there, leaving any other caller needing the same resolution to
write the same `nodes().find_map(…)` by hand.

`Graph::resolve_id` replaces it, with a unit test covering the
round-trip and the rejection of a value that was never an id.

While re-reading the diff for that question: the doc comment added in
the previous commit landed *between* `container`'s doc comment and its
signature, silently reattaching "The container node of `dag_id`" to the
new helper and leaving `container` undocumented. Restored.

No behaviour change and no wire change — same search, same call site.
Checked with clippy (`--all-targets -D warnings`), `cargo test -p
hive-jobq -p hive-c0re` (41 + 322 passed) and `nix fmt`.
2026-08-01 15:53:46 +02:00
..
lib.rs refactor(#2908): resolve a wire id in the graph, not the c0re layer 2026-08-01 15:53:46 +02:00
resources.rs refactor(#2500): encapsulate the jobq lock, drop the dead borrowed-guard layer 2026-07-19 15:24:11 +02:00
scheduler.rs fix(#2802): a group whose children were all dropped rolls up Cancelled 2026-07-27 21:27:17 +02:00