code-coordinator 0.5.492__tar.gz → 0.5.494__tar.gz

{code_coordinator-0.5.492 → code_coordinator-0.5.494}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.492
+Version: 0.5.494
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT

{code_coordinator-0.5.492 → code_coordinator-0.5.494}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.492
+Version: 0.5.494
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT

{code_coordinator-0.5.492 → code_coordinator-0.5.494}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.492",
+  "tag": "0.5.494",
   "distance": 0,
-  "node": "gf825ecb0009197eb0b97ba8d836676c545ec6a00",
+  "node": "g52be7f1fb06c8a23aaf1d850192c29dc4cf8a36f",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-09-18"

{code_coordinator-0.5.492 → code_coordinator-0.5.494}/coord/commands/drive_queue.py

@@ -124,6 +124,7 @@ from coord.overlap_predict import (
 
 if TYPE_CHECKING:  # pragma: no cover — typing only
     from coord.config import Config
+    from coord.merge_queue import QueuedMerge
 
 log = logging.getLogger(__name__)
 
@@ -4740,14 +4741,51 @@ def _run_merge_only_candidates(plan: TickPlan, config_path: Path | None) -> None
         click.echo(f"merge-only: {reason}")
 
 
+# #3396: the `stage` this call site's escalations are recorded under —
+# mirrors `ROLL_PENDING_ALERT_STAGE`/`SELF_CORDON_ALERT_STAGE` above, but
+# keyed per-entry (the entry's own `(repo_name, issue_number)`) rather than a
+# single fleet-wide slot, since more than one branch can be `checks_stale` at
+# once. `_run_auto_revalidate_checks_stale`'s cleanup pass reads this same
+# constant back to find which open escalations are its own to dismiss.
+CHECKS_STALE_ALERT_STAGE = "checks_stale"
+
+
+def _record_checks_stale_escalation(entry: "QueuedMerge", *, reason: str) -> None:
+    """Write (or refresh) the durable, human-visible escalation for *entry*
+    (#3396 item 2) — ``coord escalate list``/``coord escalate run`` and the
+    TUI already surface this table for every other "needs a human" condition
+    in this file; a `checks_stale` block that this tick cannot move forward
+    on its own now reaches it too, instead of only ever reprinting the same
+    diagnosis to the journal every ~3 minutes forever.
+
+    Best-effort: a write failure here must not take down the rest of the
+    tick — the caller already echoed the reason to stdout, which is the
+    floor this falls back to.
+    """
+    try:
+        from coord.state import record_drive_escalation  # noqa: PLC0415
+
+        record_drive_escalation(
+            entry.repo_name,
+            entry.issue_number,
+            stage=CHECKS_STALE_ALERT_STAGE,
+            reason=reason,
+            gate_readings=f"error={entry.error}" if entry.error else "gate: READY",
+            proposed_command=(
+                f"coord merge --only {entry.repo_name}#{entry.issue_number}"
+            ),
+            assignment_id=entry.assignment_id,
+        )
+    except Exception as exc:  # noqa: BLE001 — the stdout line is the floor
+        click.echo(f"  (could not record the checks_stale escalation: {exc})")
+
+
 def _run_auto_revalidate_checks_stale(config_path: Path | None) -> None:
-    """#2535: best-effort surfacing of merge-queue entries blocked SOLELY on
+    """#2535: unattended remedy for merge-queue entries blocked SOLELY on
     stale CI checks against an already-approved review — closing the gap
     where nothing periodic ever looks at such an entry on an operator's
-    behalf, so it just sits until someone notices ``--dry-run``'s
-    ``checks_stale`` line by hand (the trigger: #2530's Gate-A PR #2534 sat
-    blocked 2026-08-21 on nothing but 210 unrelated merges having landed
-    since its CI last ran).
+    behalf (the trigger: #2530's Gate-A PR #2534 sat blocked 2026-08-21 on
+    nothing but 210 unrelated merges having landed since its CI last ran).
 
     #3266: this used to auto-fire a ``gh run rerun`` (``CiStore.
     rerun_for_pr``) for exactly this shape, up to ``MAX_CI_STALE_RERUNS`` —
@@ -4756,46 +4794,89 @@ def _run_auto_revalidate_checks_stale(config_path: Path | None) -> None:
     there too: a ``gh run rerun`` replays the SAME event payload against
     the SAME base the stale checks already used, so it can never see a
     base that has since moved — which is the ONLY thing a staleness
-    reading means. Every tick that found a candidate here was spending a
-    full CI cycle (this repo's median: ~62 minutes) on a guaranteed no-op,
-    twice, before the shared ``ci_stale_reruns`` budget parked the entry
-    anyway (claude-coordinator#2972). Per this repo's "one question, one
-    answer" rule, this tick and ``process()`` must agree on the same
-    question ("should we auto-rerun CI for a checks_stale block?") — they
-    now both answer "no, park and point at a rebase" identically, rather
-    than this call site silently keeping the old answer #2197 already gave
-    up on live. See ``MAX_CI_STALE_RERUNS``'s comment in
+    reading means. See ``MAX_CI_STALE_RERUNS``'s comment in
     ``coord/merge_queue.py`` and ``ci_stale_reason``'s docstring for the
-    full reasoning and the actual remedy (rebase onto the target branch,
-    then ``git push --force-with-lease`` — the only thing that produces a
-    check against the CURRENT base).
+    full reasoning. The actual remedy is a rebase onto the target branch
+    followed by ``git push --force-with-lease`` — the only thing that
+    produces a check against the CURRENT base.
+
+    #3396: from #2535 through #3266 this call site only ever *reported*
+    that remedy — it never performed it, so a `checks_stale` entry whose
+    owning `coord drive` session had already exhausted its merge attempts
+    and exited had NOTHING left watching it: this tick re-diagnosed the
+    same block every ~3 minutes, forever, and the stale-rebase worker
+    that exists for exactly this shape (:func:`coord.conflict_fix.
+    dispatch_conflict_fix` with ``stale_rebase=True``, #3349) was never
+    dispatched. #3349 already wired that worker into
+    ``coord.notify``'s stalled-pipeline sweep (``merge_gate_checks_stale``),
+    but that sweep only runs when ``coord notify`` is invoked and
+    ``pipeline.auto_dispatch_stalled`` is on — it is not this tick, which
+    runs unconditionally every few minutes on the daemon host. Per this
+    repo's "one question, one answer" rule this call site now reuses the
+    IDENTICAL dispatcher rather than re-deriving the decision: a
+    content-preserving rebase gets force-pushed and the merge queue picks
+    it up on its own next attempt, with no operator action, exactly like
+    the #1090 reference case in the issue. A rebase that turns out to
+    conflict (or change content) still refuses and escalates — the
+    worker's own narrow briefing (:func:`coord.conflict_fix.
+    build_stale_rebase_briefing`) enforces that, not this call site.
+
+    Escalation (#3396 item 2): a candidate this function cannot move
+    forward — a conflict-fix already tried and failed against this SAME
+    error (:func:`coord.conflict_fix.has_prior_conflict_fix`), or dispatch
+    itself declined (no capable/reachable machine, no ``repo_path``) — is
+    recorded via :func:`coord.state.record_drive_escalation` under the
+    entry's OWN ``(repo, issue)``, the same durable, human-visible table
+    ``coord escalate list``/``coord escalate run`` already serve for every
+    other "needs a human" condition in this file (see
+    ``ROLL_PENDING_ALERT_REPO``/``SELF_CORDON_ALERT_REPO`` above for the
+    established one-slot-per-condition pattern; this one is naturally
+    keyed per-entry instead, since more than one branch can be
+    ``checks_stale`` at once). Before #3396 a block that "needs a human"
+    only ever reached this function's own stdout/journal line, printed
+    again unchanged every tick — never a place an operator or the TUI
+    would actually see it (the issue's own complaint: `coord drive-queue
+    status` reporting ``alert: (none)`` throughout). A candidate that
+    clears on its own (the rebase lands, or the base stops moving) is no
+    longer in the next tick's *candidates* list, so its escalation (if any)
+    is dismissed below — the table only ever holds genuinely-live blocks.
 
     Deliberately narrow — this is NOT ``merge.auto_drain`` reopened (that
     flag stays ``False`` by design; see ``docs/DRIVE_QUEUE.md`` and the
     2026-06-07 incident it guards against). This step never merges
-    anything, never mutates the queue, and never touches an entry blocked
-    on review, a real CI failure, or a conflict — it only *reports* the
-    exact shape :func:`coord.merge_queue.ci_revalidation_candidates` scopes
+    anything and never mutates the merge-queue row itself — it only ever
+    dispatches the SAME bounded, self-refusing worker
+    :func:`coord.conflict_fix.dispatch_conflict_fix` already provides
+    for the identical shape reached from a live drive/stalled-pipeline
+    sweep, gated by the SAME one-per-entry retry cap
+    (:func:`coord.conflict_fix.has_prior_conflict_fix`) — so a second
+    tick finding the same still-stale entry while a rebase attempt is
+    already running/pending does nothing, and one that already failed
+    escalates instead of retrying. It never touches an entry blocked on
+    review, a real CI failure, or a conflict — only the exact shape
+    :func:`coord.merge_queue.ci_revalidation_candidates` scopes
     ``--revalidate``'s (equally no-op) CI arm to (#1851/#1925): ``PENDING``,
     review approved, smoke fresh, CI checks green but predating the current
     base.
 
     ``MAX_CI_STALE_RERUNS``/``ci_stale_reruns`` are read nowhere in this
-    function any more — nothing here increments or checks that budget, so a
-    row already carrying a nonzero count from before this fix is left
-    exactly as ``process()`` leaves it (converges to 0 on the next
-    genuinely-fresh reading, never incremented further by this call site).
-
-    Cost-visible (#1632's posture) in the opposite direction from before:
-    there is no external spend to report any more, only a
-    :func:`coord.audit.record_audit` (operational tier) row per candidate
-    per tick, so an operator watching the trail still sees the block
-    without this function ever burning a CI cycle trying (and failing) to
-    clear it.
-
-    Deliberately NOT behind a new config flag — this is strictly a
-    supplementary read with no external action, so there is nothing new to
-    gate.
+    function — nothing here increments or checks that budget, so a row
+    already carrying a nonzero count from before #3266 is left exactly as
+    ``process()`` leaves it (converges to 0 on the next genuinely-fresh
+    reading, never incremented further by this call site).
+
+    Cost-visible (#1632's posture): dispatching a worker is real, visible
+    spend — a :func:`coord.audit.record_audit` (business tier) row marks
+    it, distinct from the operational-tier rows for a declined/escalated
+    candidate, so an operator watching the audit trail can tell "this tick
+    spent a session" from "this tick only reported a block" at a glance.
+
+    Deliberately NOT behind a new config flag — the worker it dispatches
+    already carries its own bounded, self-refusing briefing and one-shot
+    retry cap; there is nothing further to gate that
+    ``pipeline.auto_dispatch_stalled`` (the flag guarding ``coord
+    notify``'s unrelated, broader stalled-pipeline sweep) doesn't already
+    cover for that other call site.
 
     Best-effort like every other optional step in this tick (conflict
     reconciliation in ``_auto_drain_tick``, the merge-only fast path above):
@@ -4803,6 +4884,24 @@ def _run_auto_revalidate_checks_stale(config_path: Path | None) -> None:
     on a thin client — this daemon-host tick is the only place it ever
     runs, same guard :func:`_fetch_live_ci_gate`/
     :func:`_run_merge_only_candidates` use.
+
+    Known race, widened by this change (#3396 review): this tick is a new,
+    independent, ALWAYS-ON caller of ``dispatch_conflict_fix(...,
+    stale_rebase=True)`` (``deploy/coord-drive-queue.service``/``.timer``),
+    alongside ``coord notify``'s stalled-pipeline sweep (a separate systemd
+    timer, see ``docs/AGENT_OPERATIONS.md``) and a live drive's own merge
+    attempt — three independent callers for the identical shape now. The
+    shared guard (``has_prior_conflict_fix``/``_has_active_conflict_fix``)
+    is a plain board-snapshot read with no cross-process lock between them:
+    if two of these fire within the same window for the same gate-READY
+    ``checks_stale`` entry, both can independently observe "no prior fix in
+    flight" and dispatch a duplicate stale-rebase worker. Wasted spend, not
+    data loss — the second worker's push is a no-op or is itself refused —
+    but this is the first caller to fire unconditionally on a fixed timer
+    rather than behind a live drive or an opt-in flag, which widens the
+    window. A real fix needs a cross-process claim (e.g. a DB-level lock
+    keyed on the entry) rather than a snapshot read; tracked as a follow-up,
+    not fixed here.
     """
     from coord.board_service import resolve as resolve_board_service  # noqa: PLC0415
 
@@ -4815,10 +4914,32 @@ def _run_auto_revalidate_checks_stale(config_path: Path | None) -> None:
         from coord.audit import record_audit  # noqa: PLC0415
         from coord.ci_store import build_ci_store  # noqa: PLC0415
         from coord.commands._common import _load_config  # noqa: PLC0415
-        from coord.state import load_board as _load_board  # noqa: PLC0415
+        from coord.conflict_fix import (  # noqa: PLC0415
+            _has_active_conflict_fix,
+            describe_conflict_fix_decline,
+            dispatch_conflict_fix,
+            has_prior_conflict_fix,
+        )
+        from coord.network import fetch_status  # noqa: PLC0415
+        from coord.state import (  # noqa: PLC0415
+            dismiss_drive_escalation,
+            list_drive_escalations,
+            load_board as _load_board,
+        )
 
         cfg = _load_config(config_path)
-        board = _load_board()
+        # #3396: `load_board()` can legitimately return `None` (no board data
+        # at all yet). `ci_revalidation_candidates` already tolerates that
+        # (its gate reads never dereference a `None` board when the gate they
+        # guard isn't required), but `has_prior_conflict_fix`/
+        # `dispatch_conflict_fix` below unconditionally walk
+        # `board.active`/`board.completed` — an empty board is the correct
+        # "no prior assignments exist" reading for both, and keeps the two
+        # calls sharing the exact same object rather than one seeing `None`
+        # and the other a stand-in.
+        from coord.models import Board  # noqa: PLC0415
+
+        board = _load_board() or Board()
         ci_store = build_ci_store(
             cfg.ci_store.type, host=cfg.ci_store.host, token_env=cfg.ci_store.token_env,
         )
@@ -4829,34 +4950,145 @@ def _run_auto_revalidate_checks_stale(config_path: Path | None) -> None:
     except Exception:  # noqa: BLE001 — best-effort, see docstring
         return
 
+    # #3396 review: the cleanup pass below treats an escalation's absence
+    # from *candidates* as "confirmed cleared" — that's only a safe reading
+    # once we know `candidates` came from a REAL read, not from a
+    # `ci_store` that was `None`/unavailable (which `ci_revalidation_
+    # candidates` also answers with `[]`, indistinguishable by return value
+    # alone from "genuinely nothing is stale"). The `ci_store.is_available`
+    # check above, and the broader `except Exception: return` around this
+    # whole block, both already `return` BEFORE this point on exactly that
+    # ambiguous case — so reaching here at all already means the read was
+    # real. Do not restructure this so cleanup can be reached without a
+    # confirmed-available `ci_store` and a `ci_revalidation_candidates` call
+    # that returned normally; that reintroduces the "unconfirmed success"
+    # bug this comment describes (epic #2096: dismissing an escalation is
+    # asserting "resolved" — only do it from an observation, not an
+    # inability to look).
+    #
+    # #3396: drop any prior checks_stale escalation for an entry that is no
+    # longer a candidate this tick — either it landed, or the base stopped
+    # moving. Runs even when *candidates* is empty (that's the fully-healed
+    # case). Best-effort: a read/write hiccup here must not stop the actual
+    # dispatch loop below from running.
+    try:
+        live_keys = {(c.repo_name, c.issue_number) for c in candidates}
+        for esc in list_drive_escalations():
+            if esc.get("stage") != CHECKS_STALE_ALERT_STAGE:
+                continue
+            key = (esc.get("repo_name"), esc.get("issue_number"))
+            if key not in live_keys:
+                dismiss_drive_escalation(esc["repo_name"], esc["issue_number"])
+    except Exception:  # noqa: BLE001 — best-effort, see docstring
+        pass
+
     if not candidates:
         return
 
     for entry in candidates:
         label = f"{entry.repo_name} #{entry.issue_number} ({entry.branch})"
-        # #3266: no `gh run rerun` fires here any more — a same-base replay
-        # cannot clear a staleness reading, so this is visibility only, not
-        # a remedy attempt. See the docstring above and
-        # `coord.merge_queue.ci_stale_reason` for why.
-        click.echo(
-            f"auto-revalidate: {label} is checks_stale — a CI re-run cannot "
-            "clear it (same base); needs a rebase onto the target branch "
-            "and `git push --force-with-lease`, or a human running `coord "
-            "merge --only` after one"
+
+        if has_prior_conflict_fix(board, entry.assignment_id, current_error=entry.error):
+            if _has_active_conflict_fix(board, entry.assignment_id):
+                # A stale-rebase attempt is already running/pending for this
+                # entry (dispatched by this same tick earlier, a live drive,
+                # or the `coord notify` sweep) — nothing to do, and nothing
+                # to escalate: it will resolve, or fail and escalate, on its
+                # own.
+                click.echo(
+                    f"auto-revalidate: {label} is checks_stale — a "
+                    "stale-rebase conflict-fix is already in flight for it"
+                )
+                continue
+            # A prior stale-rebase (or ordinary conflict-fix) attempt for
+            # this SAME error already failed — the retry cap is spent, and
+            # re-diagnosing it every tick forever is exactly the #3396 bug.
+            # Escalate once into the durable table instead of only echoing.
+            reason = (
+                f"{label} is checks_stale and a prior conflict-fix attempt "
+                "already failed against this same block — a CI re-run "
+                "cannot clear it (same base) and the automatic rebase "
+                "already gave up; needs a human"
+            )
+            click.echo(f"auto-revalidate: {reason}")
+            record_audit(
+                tier="operational", category="merge",
+                event_type="merge_checks_stale_human_required",
+                actor="drive-queue-tick",
+                summary=reason,
+                repo=entry.repo_name, issue=entry.issue_number,
+                assignment_id=entry.assignment_id,
+                details={"pr_number": entry.pr_number, "error": entry.error},
+            )
+            _record_checks_stale_escalation(entry, reason=reason)
+            continue
+
+        pick_out: list = []
+        fix = dispatch_conflict_fix(
+            entry, board, cfg, stale_rebase=True,
+            status_fetcher=fetch_status, machine_pick_out=pick_out,
+        )
+        if fix is not None:
+            click.echo(
+                f"auto-revalidate: {label} is checks_stale — dispatched a "
+                f"stale-rebase conflict-fix ({fix.assignment_id}) to "
+                f"{fix.machine_name} (#3396: no live drive needed)"
+            )
+            record_audit(
+                tier="business", category="merge",
+                event_type="merge_checks_stale_auto_rebase_dispatched",
+                actor="drive-queue-tick",
+                summary=(
+                    f"stale-rebase conflict-fix dispatched: {label} → "
+                    f"{fix.machine_name}"
+                ),
+                repo=entry.repo_name, issue=entry.issue_number,
+                assignment_id=fix.assignment_id,
+                details={
+                    "pr_number": entry.pr_number,
+                    "merge_entry_id": entry.assignment_id,
+                },
+            )
+            # #3396 review: an earlier tick may have already written a
+            # `checks_stale` escalation for this SAME entry (dispatch
+            # declined that time — no machine, no repo_path) before a later
+            # tick found dispatch available and actually fired the worker.
+            # Without this, `coord escalate list`/the TUI keep showing
+            # "needs a human" for an entry that in fact now has a
+            # stale-rebase worker actively running against it, until it
+            # eventually drops out of `candidates` entirely. Best-effort —
+            # a dismissal failure here must not undo the dispatch above.
+            try:
+                dismiss_drive_escalation(entry.repo_name, entry.issue_number)
+            except Exception:  # noqa: BLE001 — best-effort, see docstring
+                pass
+            continue
+
+        # Dispatch declined before ever starting a rebase — no capable or
+        # reachable machine, no `repo_path` configured, or a flapping agent
+        # (#3353). Still `checks_stale`, still gate-ready, and still nobody
+        # is going to clear it on its own — surface it the same durable way
+        # a genuine retry-cap exhaustion does, rather than a print-only line
+        # nothing but the journal ever sees.
+        decline_reason = describe_conflict_fix_decline(pick_out)
+        reason = (
+            f"{label} is checks_stale with a content-preserving rebase "
+            f"expected to clear it, but dispatch declined: {decline_reason}"
         )
+        click.echo(f"auto-revalidate: {reason}")
         record_audit(
             tier="operational", category="merge",
             event_type="merge_checks_stale_parked",
             actor="drive-queue-tick",
             summary=(
                 f"checks_stale: {label} needs a rebase, not a CI re-run "
-                "(#3266) — a same-base `gh run rerun` can never clear "
-                "staleness"
+                f"(#3266); auto-dispatch declined: {decline_reason} (#3396)"
             ),
             repo=entry.repo_name, issue=entry.issue_number,
             assignment_id=entry.assignment_id,
-            details={"pr_number": entry.pr_number},
+            details={"pr_number": entry.pr_number, "decline_reason": decline_reason},
         )
+        _record_checks_stale_escalation(entry, reason=reason)
 
 
 def _run_resume_probe(entry: QueueEntry) -> ProbeResult:

{code_coordinator-0.5.492 → code_coordinator-0.5.494}/coord/db.py

@@ -666,6 +666,129 @@ def rollback_after_driver_error(conn: Any | None, exc: BaseException) -> None:
         pass
 
 
+def undo_pending_write(conn: Any | None, exc: BaseException, *, undo: Callable[[], Any]) -> None:
+    """Run *undo* — a compensating statement touching only THIS write's own
+    row — after *exc*, the #3382 sibling of
+    :func:`rollback_after_driver_error` for a writer whose own
+    ``conn.commit()`` call, not just the statement before it, can raise.
+
+    :func:`rollback_after_driver_error` deliberately no-ops for a plain
+    SQLite error (see its docstring): that is correct when the failure is a
+    STATEMENT that never got to write anything — SQLite's ``SQLITE_BUSY``,
+    hit while acquiring the lock a write needs, leaves nothing applied, so
+    simply re-running the whole write closure from scratch (what
+    :func:`retry_on_locked` does) is exactly as good as a rollback.
+
+    That reasoning does not hold when it is ``conn.commit()`` itself that
+    raises. WAL-checkpoint contention can make ``COMMIT`` hit
+    ``SQLITE_BUSY`` *after* the statement(s) before it already applied
+    inside the still-open transaction — the write is neither committed nor
+    undone, so it sits there, genuinely pending, on ``coord.db``'s shared
+    process-wide connection, ready for a completely unrelated handler's next
+    unrelated ``commit()`` to durably persist it later. #3382: this is
+    exactly how a ``review_claims`` row survived two callers who each saw
+    their own ``/review-claim`` POST fail with a 503 — neither call's own
+    retry-free write had anything guarding its ``commit()``, so the pending
+    insert outlived both failed calls and was swept up by a later,
+    completely unrelated write on the same shared connection.
+
+    A bare retry of the closure does not fix this the way it fixes a failed
+    statement, either: an ``INSERT OR IGNORE`` re-run against its own
+    still-pending prior insert reads back as a conflict (``rowcount == 0``),
+    so the retry silently misreports "someone else already holds this
+    claim" about a claim only this process's own earlier, abandoned attempt
+    took.
+
+    **Why a compensating statement, and not a transaction-level undo of any
+    kind (#3382 review rounds 1 and 2).** Two earlier shapes of this
+    function were both rejected, for the same underlying reason:
+
+    * ``conn.rollback()`` (round 1). On ``coord.db``'s shared, process-wide
+      SQLite singleton (see this module's own docstring), that discards
+      *every* other thread's not-yet-committed statement too — this process
+      dispatches other ``_*_local`` writers through ``run_in_threadpool`` on
+      real OS worker threads (the daemon's periodic tick, the ``/board``
+      build, ``/assignment/*`` handlers), and Python's ``sqlite3`` joins ANY
+      thread's statement issued on this one connection between commits into
+      the SAME open transaction. An unrelated writer that already got
+      ``sql.execute``/``sql.insert_ignore``'s success back (nothing in this
+      tree commits internally — see ``coord/sql.py``) then silently loses it
+      when its own later ``conn.commit()`` no-ops or raises ``cannot commit
+      - no transaction is active`` — this issue's own second logged symptom.
+
+    * ``SAVEPOINT`` + ``ROLLBACK TO SAVEPOINT`` (round 2), whether the
+      savepoint name is a shared literal or made unique per call. Unique
+      names fix only the narrower half of the problem (two concurrent calls
+      resolving each other's marker, since SQLite binds a name to the most
+      recently established savepoint of that name). They do **not** fix the
+      half that matters: ``ROLLBACK TO SAVEPOINT`` reverts the database to
+      its state *just after that savepoint was established*, so it undoes
+      every statement issued since — including another thread's, which this
+      writer has no business undoing — and destroys that thread's own
+      savepoints along the way. Verified against a real ``sqlite3``
+      connection (Python 3.12, SQLite 3.45): with two distinctly-named
+      savepoints opened back to back and one row inserted after each,
+      ``ROLLBACK TO`` the OUTER (uniquely-named) savepoint removes BOTH
+      rows. A transaction-scoped undo simply cannot express "mine only" on a
+      connection several threads write through.
+
+    So the undo is row-scoped instead: *undo* issues one statement that
+    names this write's own row and nothing else (delete the row this call
+    inserted, identified by its own ``claimed_at`` stamp; re-insert the row
+    this call deleted, with the ``claimed_at`` it read back first). It is
+    exact regardless of how other threads' statements interleave with this
+    one — before the failure or after it — because it never refers to their
+    rows.
+
+    It also degrades better than a transaction-level undo when an unrelated
+    thread's ``commit()`` lands *between* this write's statement and this
+    recovery: a savepoint would already have been destroyed by that commit
+    (``COMMIT`` releases all savepoints), leaving ``ROLLBACK TO`` to fail
+    and this write's row durably committed and leaked — precisely the
+    incident. The compensating statement instead stays pending and is
+    flushed by whichever ``commit()`` reaches it next (this closure's own
+    retry, or another writer's), so the net effect on this row is still
+    nothing.
+
+    Call this from the ``except sql.driver_errors():`` block of a write
+    closure that both executes a statement *and* calls ``conn.commit()``
+    itself, and **only when that closure's own statement actually applied**
+    (``cursor.rowcount``) — a statement that failed applied nothing, so
+    there is nothing to compensate, the same "a failed STATEMENT applies
+    nothing" reasoning :func:`rollback_after_driver_error` already
+    documents. Today's callers are the ``review_claims``/``smoke_claims``
+    claim and release writes in ``coord/state.py`` (#3113/#3333), the two
+    sites where "did this claim land" is an exclusive-ownership decision the
+    rest of the system relies on, unlike most of this module's writers where
+    a duplicate-on-retry UPDATE/DELETE is harmless.
+
+    Unlike :func:`rollback_after_driver_error`, this does not inspect *exc*
+    for a SQLSTATE: the plain-SQLite case above is exactly what it exists to
+    cover. On Postgres it is a harmless no-op in practice — a failed
+    ``COMMIT`` there aborts the whole transaction (so *undo* raises
+    ``InFailedSqlTransaction``, suppressed below) and
+    :func:`retry_on_locked`'s own :func:`rollback_after_driver_error` call
+    has already undone this write for real; ``get_connection()`` also hands
+    each THREAD its own connection there (see this module's docstring), so
+    no other thread's statement was ever at risk.
+
+    Same suppression rule as :func:`rollback_after_driver_error`: a ``None``
+    *conn* is a no-op, and a failure of *undo* itself is swallowed so it
+    never masks *exc*, the exception actually worth seeing. If the
+    compensating statement cannot run either (sustained contention
+    outlasting even this), this write's own row is left pending for the next
+    writer's eventual commit/rollback to resolve — the same residual,
+    already-accepted risk :func:`rollback_after_driver_error`'s own
+    suppressed-failure path carries today, not a new one.
+    """
+    if conn is None:
+        return
+    try:
+        undo()
+    except Exception:  # noqa: BLE001 — never mask the caught driver error
+        pass
+
+
 # #2538: a handful of consecutive short retries — long enough to ride out a
 # concurrent writer (the daemon's own passive tick, another `coord merge`/
 # `coord notify` invocation) that only holds the DB for a moment, short

{code_coordinator-0.5.492 → code_coordinator-0.5.494}/coord/merge_queue.py

@@ -3724,16 +3724,24 @@ def ci_revalidation_candidates(
     `rerun_for_pr` replays the same run against the same base it already
     used, so it can never see the new one. `process()`'s OWN #2197
     auto-rerun for this trigger was dropped for that reason (see
-    `MAX_CI_STALE_RERUNS`'s comment), and `coord.commands.drive_queue
-    ._run_auto_revalidate_checks_stale` (the unattended periodic call site)
-    was fixed the same way in the same change — it still calls this
-    function to find the candidates, but only to report them, never to
-    rerun anything. The one remaining caller that still calls
-    `rerun_for_pr` on what this returns is `coord.commands.merge
+    `MAX_CI_STALE_RERUNS`'s comment). The one remaining caller that still
+    calls `rerun_for_pr` on what this returns is `coord.commands.merge
     ._apply_ci_revalidation` (the opt-in ``--revalidate`` CI arm) — equally
     unable to clear the block, but lower severity since a human has to
     explicitly ask for it. Left as-is here: fixing it is a change to that
     module, out of this function's/file's scope, and a tracked follow-up.
+
+    #3396: `coord.commands.drive_queue._run_auto_revalidate_checks_stale`
+    (the unattended periodic call site) still calls this function to find
+    the candidates, but no longer only to report them — a #3266-through-
+    #3396 gap meant a `checks_stale` entry whose owning `coord drive`
+    session had already exited was never seen by anything that could
+    actually clear it, only re-diagnosed forever. That call site now
+    dispatches the SAME bounded, self-refusing stale-rebase worker
+    (:func:`coord.conflict_fix.dispatch_conflict_fix` with
+    ``stale_rebase=True``) a live drive or `coord notify`'s stalled-pipeline
+    sweep would already use for this exact shape — never a `gh run rerun`,
+    which stays the known no-op described above.
     """
     if ci_store is None or not ci_store.is_available:
         return []