Reply controller cannot record rejected duplicate batches or recover pass-2 validation #35

Problem

The PR reply controller can refuse to record an independent validator's rejected verdict because the rejected draft contains a duplicate reply. This leaves the controller with no active rejection, so it then refuses the permitted corrected pass-2 batch. The workflow cannot recover without bypassing its required rejection history.

Observed with dk-workflows 1.1.19 on Codex/Linux, while iterating scylladb/python-driver#1146. The rejection/registration failure was retained from the previous run; a subsequent run verified the same head and reconciled the controller but could not recover the missing rejection. The branch was already fixed, 436 focused tests passed with 11 expected failures, and all 34 CI checks passed. The remaining minor thread still lacked acknowledgement and resolution, blocking workflow completion.

The same failure was reproduced offline against current main, version 1.1.20, at commit 38317beb335654efc2ab4008ecd2470637525aef, using the repository's real controller and existing mocked GitHub fixture. The full PR workflow was not rerun against 1.1.20.

Observed sequence

1. A reply batch proposed the Major explanation again, although that exact answer was already published at discussion_r4369585171. The batch also included the remaining Minor acknowledgement.

2. The independent validator returned status: rejected, pass: 1, bound to the original batch digest. Its correction was to retain the verified Major answer as a skipped mapping and prepare only the remaining Minor reply against fresh evidence.

3. Submitting that rejected batch and verdict to reply_passes.py publish hits the duplicate-answer guard before verdict recording:

   request already has a verified answer; retain its mapping and skip it
   

4. The rejection is absent from controller history. The retained state has active: null, blocked: null, and phase inline, despite the externally retained pass-1 rejection.

5. reconcile succeeds in verifying existing replies, but cannot import or adopt the missing rejection.

6. A corrected, independently approved pass-2 batch then fails because there is no recorded active rejection:

   first verdict must be pass 1
   

Submitting the correction as a fresh pass 1 would discard the required correction history. Editing the original rejected batch would invalidate its bound digest. The documented controller exposes only next, publish, reconcile, and resolve; no rejection-registration recovery operation is available. No duplicate reply, state reset, helper modification, or direct GitHub mutation was used to work around the failure.

Why recovery fails

Controller.publish() checks for already answered requests and requires the latest snapshot before reading the independent verdict. The duplicate check raises immediately, so even a rejected verdict never reaches persistence:

Pass-2 admission requires an existing rejected entry. Creating that entry, copying the batch/verdict, and saving the rejection all happen after the publication-oriented checks:

reconcile() preserves a rejection only when an active entry was already recorded; it has no path for the externally retained verdict rejected before persistence:

The existing resume test covers a rejection that successfully reached persistence, rather than a rejected draft stopped before recording:

Offline reproduction

A local reproducer uses ReplyPassesTest and its mocked GitHub API, with no network calls or real PR mutations:

1. Publish the fixture's first inline answer successfully.
2. Add another actionable inline request and reconcile to fresh inline evidence.
3. Prepare a batch containing both the already answered request and the new request. Submit a valid independent rejected pass-1 verdict.
4. Assert that the duplicate guard raises, history remains unchanged, and active is still null.
5. Reconcile, prepare a corrected batch that skips the existing answer and replies only to the new request, and submit an approved pass-2 verdict from the same validator.
6. Assert the first verdict must be pass 1 failure and no additional mocked publication.

Observed output:

{
  "rejected_batch_registration_error": "request already has a verified answer; retain its mapping and skip it",
  "rejection_recorded": false,
  "reconcile_recovers_missing_rejection": false,
  "corrected_batch_pass_2_error": "first verdict must be pass 1",
  "history_entries_before_and_after": [1, 1],
  "active_after_registration": null,
  "mock_posts_before_and_after_failed_attempts": [1, 1],
  "network_calls": 0
}

Expected behavior

• Retain a valid independent rejection and its original batch/verdict identity even when the draft fails a publication-specific guard. Rejection recording must not publish or authorize an invalid draft.
• Provide a supported, auditable recovery path for the already retained external pass-1 rejection, preserving its original batch digest, validator identity, evidence, and correction count.
• Permit exactly the existing same-validator pass-2 correction against fresh evidence, including corrections that remove all replies. Reconciliation and restart must preserve the first rejection and any final rejection.
• Continue to reject duplicate publication, stale evidence, wrong PR/selection/head, malformed or non-independent verdicts, wrong-validator corrections, extra attempts, and uncertain publication replay.
• Add focused regression coverage for rejected duplicate batches before persistence, snapshot-freshness failures during rejection submission, recovery after restart, corrected pass 2 without duplicate publication, and final-rejection enforcement.

A possible implementation is to separate validated rejection recording from approved-batch publication checks, or add an explicit guarded adoption operation. Simply skipping duplicate checks or restarting validation at pass 1 would weaken the existing guarantees.

Related: #9 addresses edited semantic-answer evidence; #30 addresses post-reply review-scope provenance. This report concerns rejection persistence before either recovery or publication.