A marker stripped by hand lets a fresh run's K3 adopt a PR a live run is driving

Aperta
  • Qualcosa non va?
#462 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github, python
Ambito
distributed-systems

Direzione di ricerca

Read ADR 0004, especially K3 and D9.3, the decision record for #414, and the runtime model in AGENTS.md. Determine whether evidence such as review-round comments or follow-up issues can safely make K3 refuse, and assess how often that would block legitimate adoption; the issue frames this as a design decision and records the evidence check's blind spot.

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

Descrizione

enhancement

Follow-up to #414, deferred by its decision record under Residuals. It applies once PR #460 merges.

Problem

Under #414 a fresh run never adopts a marked PR. K3 still adopts an open unmarked PR that the run's entry recorded on the issue's derived branch (ADR 0004 K3). So if someone removes the marker from a PR a live run is driving, the PR looks to a fresh run like one it may adopt, and K3 writes the fresh run's owner into it.

Impact

The live run blocks with pr-owner at its next check, so two runs do not keep driving the PR. Ownership has still moved without the operator's --take-over, which is the one authority #414 grants for that. The stop's reason then names the fresh run as owner, which an operator would read as a deliberate handover.

It takes a human or a tool editing the body to remove the marker, so this should be rare. No occurrence is known.

Constraints

  • GitHub is the only place two environments meet, and no leases, heartbeats or coordinator are allowed (AGENTS.md, Runtime model).
  • An unmarked PR does not say how it got that way. One opened by hand on the branch and one whose marker was stripped look the same.
  • A signal on GitHub may only make a run refuse, never let it adopt (ADR 0004 D9.3).

Desired outcome

A decision on whether K3 should refuse when the PR shows evidence of an earlier controller, such as review-round comments or follow-up issues, or whether this stays a documented residual. Option 2 in #414 proposed that evidence check, and #414 records its blind spot: nothing shows before the first review is posted.

Unknowns

Whether the evidence check would refuse K3 cases that are legitimate today. That has not been measured.

Lingua principale
Python
Stelle
0
Fork
0
Merge medio
6h 7m
PR unite (30g)
107

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 iceboundrock/AutoForge

Tutte le issue di iceboundrock/AutoForge

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.