Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Determinism Tier 2: remediation must be atomic and idempotent under partial failure

Aperta
  • Qualcosa non va?
#420 0 commenti 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à
Tranquilla
Stack tecnologico
git, github, python
Ambito
backend, devtools

Direzione di ricerca

Start by reading builtin_handlers.py around lines 233–240 and 806–836, then orchestrator.py around lines 409–410 to trace how remediation outcomes are handled. Identify existing handler and audit-run storage conventions before choosing how to record attempts. Done means retries can detect already-applied API state, failures warn about possible partial state, and a later run can warn about prior attempts.

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

Descrizione

module-core

Summary

Remediation actions with side effects (GitHub API calls, gh
subprocess invocations, git push) currently have no atomicity
guarantee and no idempotency check. A network drop mid-action can
leave the repo or upstream in a partial state that darnit does not
detect on the next run.

This is Determinism Tier 2 as applied to the remediation phase --
side effects are expected but half-applied side effects must be
surfaced, not hidden.

Concrete gaps

  • packages/darnit/src/darnit/sieve/builtin_handlers.py:806-836 --
    api_call_handler returns INCONCLUSIVE with
    requires_execution: True but has no idempotency key. If a network
    drop kills the process after the API call succeeded but before
    darnit recorded the outcome, a subsequent run will re-fire the
    same call.
  • packages/darnit/src/darnit/sieve/builtin_handlers.py:233-240 --
    exec handler for gh commands (branch protection PATCH, ruleset
    creation) captures failure but doesn't record whether partial
    state was left on GitHub. A rule set half-applied can hide behind
    a subsequent "already exists" error on retry.
  • packages/darnit-baseline/src/darnit_baseline/remediation/orchestrator.py:409-410
    -- needs_review=True marks unsafe handlers but doesn't track
    partial-failure state across runs. Same handler failing on run N
    and re-attempted on run N+1 has no persisted "we tried this
    before" signal.

Scope

  • For api_call_handler: add a pre-execution check that reads the
    target resource (idempotency key: URL + method + relevant payload
    hash). If the desired state is already present, skip and log
    "already applied."
  • For gh command remediation: on failure, log a WARN with the
    specific state that may be partial (e.g., "branch protection
    attempted; verify at https://github.com/owner/repo/settings/branches").
  • Persist a per-audit-run remediation attempt log
    (.darnit/remediation-attempts.json or via a new
    RemediationLogStore Protocol -- consider whether to piggyback on
    the feature 033 store abstraction). Next run reads this log to
    detect stale-retry situations and warn operator.

Non-goals for v0

  • Full transactional rollback (out of scope for shell-out
    remediations; document the risk instead).
  • Retrying failed remediations automatically (masks the underlying
    gap; leave to operator).
  • Adding a new store Protocol for remediation logs (may be worth it;
    defer to spec time).

Constitution alignment

  • II. Conservative-by-Default: an unknown partial state is worse
    than a clean failure. Loud logging of partial-state risk preserves
    the operator's ability to reason about their repo's actual state.
  • III. TOML-First: any per-handler idempotency-key configuration
    belongs in the handler TOML.

Related

  • #418 (Determinism Tier 1) -- atomic file writes handled there.
  • #419 (Determinism Tier 2 audit-side) -- same problem in the audit
    phase.
  • Determinism Tier 3 (LLM remediation review checkpoint, filed
    alongside this one) -- separate concern from atomicity but same
    phase.
Lingua principale
Python
Stelle
22
Fork
27
Merge medio
2g 28m
PR unite (30g)
40

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 darnitdevorg/darnit

Tutte le issue di darnitdevorg/darnit

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.