Delivery watchdog: add run-liveness and decision-effect checks, not only rate alarms

Chiusa Adatta ai principianti
  • Qualcosa non va?
#2,166 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #2183 di @remigiusz-antczak — integrata

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Ambito
documentation

Direzione di ricerca

Trova le indicazioni del watchdog per agentic-delivery e agentic-ceo, poi leggi come descrivono attualmente gli allarmi di frequenza. Aggiungi, accanto agli allarmi di frequenza, indicazioni per i controlli di vitalità dell’esecuzione e di effetto delle decisioni, con un esempio per ciascuno. Il lavoro è completato quando le indicazioni trattano entrambi i controlli e includono entrambi gli esempi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Finding: a conductor's delivery watchdog that measures only outcomes (merges per hour, ready-queue age) cannot tell a slow pipeline from a stopped one. A silently dead merge-queue run and a posted-but-unexecuted decision both read as "slow" for hours.

Observed (one multi-agent repo, one day):

  • A merge-queue run started with 2 PRs, posted no outcome, and no new run started for over 2 hours. The watchdog alarmed on the merge rate the whole time and never named the cause.
  • The conductor had decided to fill each run to 12 PRs. Over the next 24 hours, 35 runs carried a median of 2 to 3. No check compared the decision with the executor's next run.
  • 12 ready PRs rode 119 runs between them with no failure attributed to them, and never landed.

Proposed change (agentic-delivery / agentic-ceo):

  1. Run liveness. Alarm when the newest queue-run start is older than 1.5x the run's expected duration while ready work exists. The data is usually already present in the per-PR "queued in run X" markers.
  2. Decision effect check. When a conductor posts a decision to an executor, record its observable effect (for example "next run size >= 12") and assert it on the next watchdog cycle. A decision with no effect check decays silently.
  3. Rides without landing. Count each ready item's rides with no attributed failure. A high count points at dead or aborted runs, not at the item.

Done when: the watchdog guidance lists liveness and decision-effect checks next to the rate alarms, with one example each.

Lingua principale
Python
Stelle
2
Fork
1
Merge medio
1h 29m
PR unite (30g)
551

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di protocol/perun

Tutte le issue di protocol/perun

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.