Skip to content

feat(pr-fix): reactivate on fresh feedback with bounded reconciliation #1253

Open

Description

@joryirving

Why

Fresh actionable feedback must not remain stranded behind an earlier FIXED, operational PARKED, or structured WAITING_EXTERNAL disposition. This is the policy/execution half of design #1244, after the evidence/fencing and external-dependency prerequisites.

Implementation

  • Reuse authoritative per-generation freshness/attempt-snapshot decisions from #1249 and the structured dependency contract from #1250.
  • Implement one bounded, idempotent evaluateRecovery transition used both by event-driven enqueue and periodic authoritative re-read. Preserve existing in-flight worker ownership; a new observation during execution is recorded for post-dispatch settlement, not a second active hand-out.
  • Reactivate FIXED on new actionable evidence, budget-available operational PARKED after allowed cooldown, and a structured WAITING_EXTERNAL when its dependency trigger fires or a fresh independent review arrives. New actionable feedback opens a charged attempt; normal external-dependency rechecks remain uncharged.
  • Never override BLOCKED human decisions, maintainer holds, infra/security fail-closed parks, max-attempt/max-reclaim exhausted parks, or merged/closed/archived PRs. Record newer evidence and surface a stale-disposition flag rather than silently dropping it.
  • Fence all reactivation, settlement and terminal reap transitions on live generation/snapshot and owner acknowledgements; old workers cannot settle fresh work. Preserve immutable PrFixHistory, cap/cooldown defaults, and existing operator requeue escapes.
  • Bounded pagination, re-read limits, retry backoff, restart-safe cursors/timestamps and audit actor/evidence metadata; no new Courier model/phase dependency.

Acceptance / negative controls

  • Feedback during execution, delayed webhook first discovered after FIXED, new comment during external wait, and genuinely new feedback on budget-available operational PARKED eventually produce exactly one new generation.
  • Duplicate/replayed/out-of-order reviews, previously seen persistent merge conflicts, re-read after bounded-key eviction, and resolved review threads never requeue.
  • Cap exhaustion parks with operator-visible stale evidence; human hold, old-worker settlement, claim ack race and merged PR never lose ownership or reopen.
  • Missed webhook repaired by periodic reconcile; parallel reconcile/event/requeue calls idempotent. Exhaustive transition-table tests corresponding to #1248 and no unbounded retry loops.

Dependencies

Blocked by #1249, #1250, and accepted design PR #1248. No auto bulk requeue of legacy waiting records.

Activity

  1. joryirving commented on Oct 15, 2026

    @joryirving
    ContributorAuthor

    2026-10-15 production-first sequencing

    This P1 remains blocked on #1249 and #1250, both now status/ready because the design PR #1248 is merged. Prioritize #1250 first to stop no-patch/no-dependency outcomes from masquerading as external waits; implement #1249's durable, authoritative fresh-evidence contract next; then ship the minimal bounded reactivation in this issue. Keep the completed #1119/#940 behavior and generation fences; do not rebuild the queue.

    Operator-visible acceptance: new actionable PR feedback cannot sit indefinitely behind an earlier FIXED, budget-available operational PARKED, or fake WAITING_EXTERNAL disposition; genuine external waits and human/security holds remain safe. Show an existing PR with newly posted review/CI evidence re-entering worker admission exactly once, including webhook-loss/reconcile recovery, without manual database edits.

    Courier's model-capacity handoff has its own immediate P1 Courier #327. Neither #1249/#1250/#1253 nor generic abandonment reconciliation (#1251/#1254) is a new prerequisite for that already-implemented fenced capacity handoff. Avoid tying the two efforts together or starting a second recovery architecture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions