Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#420 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
git, github, python
領域
backend, devtools

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Python
スター
22
フォーク
27
平均マージ
1日 19時間
マージ済み PR（30日）
39

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

darnitdevorg/darnit のほかの issue

darnitdevorg/darnit の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。