knowledge: remove the redundant concurrent boot-time pull that races with reset --hard, and clean -fd untracked drift too

This commit is contained in:
damocles 2026-08-24 14:30:54 +02:00 committed by mara
commit 30067cbcb2
2 changed files with 30 additions and 18 deletions

View file

@ -350,17 +350,19 @@ async fn cmd_serve(
}
});
// Knowledge periodic pull: hourly fallback in case the webhook is
// missed (e.g. hive-c0re was down during a push). First fires at
// startup (immediate pull after the clone is already present).
// missed (e.g. hive-c0re was down during a push). Deliberately does
// NOT also fire an immediate pull at startup the way this task used
// to: `auto_update::run`'s `NodeKind::KnowledgePull` DAG node (spawned
// separately, a few lines up) already does that unconditionally on
// every boot. The two used to run concurrently with no lock between
// them, both `git pull --ff-only`-ing the same working tree — a real
// race, and the likely root cause of the "local changes would be
// overwritten" wedge this file's `pull()` now defends against
// (`reset --hard` before every pull). Removing the redundant caller
// fixes the race at its source instead of just self-healing after it.
let mut knowledge_shutdown = coord.shutdown_rx();
let knowledge_coord = coord.clone();
tokio::spawn(async move {
// Initial pull — reconcile any commits that landed while c0re
// was offline. Not fed to the health tracker: a startup miss is
// expected (the clone may not exist yet) and is logged at debug.
if let Err(e) = knowledge::pull(&knowledge_coord).await {
tracing::debug!(error = ?e, "knowledge: startup pull skipped (no clone yet?)");
}
// Persistent-failure → banner. An hourly sweep that keeps failing for
// several hours means the operator's `/knowledge` is drifting; raise a
// warn banner after 3 consecutive misses so a one-off network blip