vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

fix(#2971): thread the queue node id into nix_logged

Browse source 
`nix_logged` wrote its `build_logs` row with `node_id = None`, so a deploy's
eval/relock log was reachable from the agent+kind+time listing but not from
the queue node that ran it.

The comment justifying the `None` said both callers are "reached from outside
the queue as well as from inside it". That is no longer true: `verify_commit`
and `prepare_deploy` have exactly one caller each, and both sit under the
`MergeVerify` / `DeployApply` arms of `exec.rs`'s node dispatch, where the
`NodeId` is already in scope.

Threads `Option<u64>` from the dispatch down, mirroring `prebuild_toplevel`'s
existing `Some(id.get())` at exec.rs:241. Kept as `Option` rather than a bare
`u64` because `meta::prepare_deploy` / `meta::verify_commit` are public API and
a future non-queue caller has no node to name; the comment now says that
instead of the stale claim.

No behaviour change beyond the log row gaining its node link.
This commit is contained in:
atlas 2026-08-03 17:47:07 +02:00 • committed by mara
commit 6ce71556e2
3 changed files with 51 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

14
hive-c0re/src/job_queue/exec.rs
View file

@ -103,9 +103,11 @@ pub(super) async fn run_node(
// that could never fire.
NodeKind::WritePermFile { payload, .. } => run_write_perm_file(coord, agent, payload).await,
NodeKind::Reparent { moves } => run_reparent(coord, moves).await,
NodeKind::MergeVerify { approval_id, .. } => run_merge_verify(coord, *approval_id).await,
NodeKind::MergeVerify { approval_id, .. } => {
run_merge_verify(coord, *approval_id, id).await
}
NodeKind::DeployApply { approval_id, .. } => {
run_deploy_apply(coord, *approval_id).await.map(|()| {
run_deploy_apply(coord, *approval_id, id).await.map(|()| {
super::templates::deploy_rebuild_nodes(&builder, agent, *approval_id);
})
}
@ -574,8 +576,8 @@ async fn run_reparent(
/// Deploy phase 1 — drift gate, fetch, eval-verify. Mutates nothing, so a
/// failure here cancel-cascades the rest of the subtree with the forge and the
/// applied repo exactly as they were.
async fn run_merge_verify(coord: &Arc<Coordinator>, approval_id: i64) -> Result<()> {
crate::actions::run_deploy_merge_verify(coord, approval_id).await
async fn run_merge_verify(coord: &Arc<Coordinator>, approval_id: i64, id: NodeId) -> Result<()> {
crate::actions::run_deploy_merge_verify(coord, approval_id, Some(id.get())).await
}
/// Deploy phase 2 — the irreversible half: ff-merge, then phase 1 of the
@ -587,8 +589,8 @@ async fn run_merge_verify(coord: &Arc<Coordinator>, approval_id: i64) -> Result<
/// their `MetaSync` declares is re-entered rather than deadlocked against the
/// ancestor already holding it. On failure nothing is appended and the tail
/// compensates, exactly as before.
async fn run_deploy_apply(coord: &Arc<Coordinator>, approval_id: i64) -> Result<()> {
crate::actions::run_deploy_apply(coord, approval_id).await
async fn run_deploy_apply(coord: &Arc<Coordinator>, approval_id: i64, id: NodeId) -> Result<()> {
crate::actions::run_deploy_apply(coord, approval_id, Some(id.get())).await
}
/// Deploy phase 3 — close the staged-lock window once the appended rebuild has