job_queue: add NodeKind::Reparent (topology moves as a queue node, #2719)
This commit is contained in:
parent
766b1f71fb
commit
05b373474a
6 changed files with 177 additions and 5 deletions
|
|
@ -420,3 +420,28 @@ pub fn meta_update(
|
|||
) -> u64 {
|
||||
submit_and_emit(coord, templates::meta_update(inputs, source, reason, None))
|
||||
}
|
||||
|
||||
/// Topology move(s) as a queue DAG. `moves` is `(child, new_parent)` pairs —
|
||||
/// one entry for `set-parent`, N for `set-parent-bulk`. Not yet wired to the
|
||||
/// `set-parent`/`set-parent-bulk` HTTP handlers or the `hivectl`/MCP
|
||||
/// `SetParent` surface — those still call `Coordinator::reparent*_with_notify`
|
||||
/// directly, which blocks until the commit lands and returns a synchronous
|
||||
/// `ok`/`err`, unlike every other queue-backed op. Whether that call-site
|
||||
/// swap should keep the synchronous contract or go fire-and-forget (submit
|
||||
/// returns a DAG id immediately, like everything else in this module) is an
|
||||
/// open question — exists so the `NodeKind::Reparent` shape is exercised
|
||||
/// end-to-end (tests, and any future caller) ahead of that call-site swap.
|
||||
#[allow(
|
||||
dead_code,
|
||||
reason = "landed ahead of the server.rs/dashboard::topology call-site swap, pending an \
|
||||
answer on whether that swap should be synchronous or fire-and-forget — \
|
||||
exercised today by job_queue::tests"
|
||||
)]
|
||||
pub fn reparent(
|
||||
coord: &Arc<Coordinator>,
|
||||
moves: Vec<(hive_types::Ident, Option<hive_types::Ident>)>,
|
||||
source: Source,
|
||||
reason: String,
|
||||
) -> u64 {
|
||||
submit_and_emit(coord, templates::reparent(moves, source, reason))
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in a new issue