code-coordinator 0.5.295__tar.gz → 0.5.296__tar.gz

{code_coordinator-0.5.295 → code_coordinator-0.5.296}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.295
+Version: 0.5.296
 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.295 → code_coordinator-0.5.296}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.295
+Version: 0.5.296
 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.295 → code_coordinator-0.5.296}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.295",
+  "tag": "0.5.296",
   "distance": 0,
-  "node": "g6f3f2c4c263d6bd9620eee9c2030c0ed984ee448",
+  "node": "ga711fc248f5a8207d97fdc8ec5709d04beb8f505",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-29"

{code_coordinator-0.5.295 → code_coordinator-0.5.296}/coord/drive_queue.py

@@ -3759,18 +3759,29 @@ def _reconcile_blocked(
     except a CONFIRMED-clear reading OR a probe that came back unreadable
     (#2806), which is deliberate: a `blocked` entry this sweep cannot say
     anything new about must render EXACTLY as it did before #2230 existed.
-    Three ways to land there:
+    Four ways to land there:
 
     * the block is PERMANENT (:func:`is_permanent_block_reason`) — #1844's
       guard refusal or #2019's dead end — neither of which any amount of
       re-checking can ever change;
+    * the block is `_resolve_prereqs`'s own unsatisfiable ``after=`` verdict
+      (:func:`_is_unsatisfiable_prereq_reason`, #2935) — a `waiting` entry
+      that never reached `running` has no assignment and no branch, so
+      there is categorically no merge-queue row for THIS sweep to have any
+      opinion about; the entry's fate is `_reconcile_blocked_after`'s alone
+      to decide, from the ``after=`` graph, on this or a later tick. Checked
+      — and returned from — before :func:`_blocked_gate_reading` even runs,
+      specifically so :func:`_reconcile_blocked_unreadable` never gets the
+      chance to overwrite `last_reason` with a merge-gate "could not read"
+      sentence and clobber the one marker `_reconcile_blocked_after` needs
+      to recognise this row again next tick — see #2935 for the incident a
+      missing version of this branch caused;
     * there is no evidence either way (:func:`_blocked_gate_reading` returns
       ``None``) AND :func:`_reconcile_blocked_unreadable` also has nothing
-      to add — an entry that never reached the merge queue at all (a
-      dispatch-time failure, an unsatisfiable ``after=``) has nothing this
-      sweep can cheaply re-check, and guessing would be exactly the "worse
-      than nothing" sweep the issue warns a naive "retry everything" pass
-      would be;
+      to add — a dispatch-time failure (#2589's two per-run shapes) has
+      nothing this sweep can cheaply re-check, and guessing would be
+      exactly the "worse than nothing" sweep the issue warns a naive
+      "retry everything" pass would be;
     * the gate is CONFIRMED still shut — the common, honest outcome for a
       `blocked` entry that has not in fact recovered yet.
 
@@ -3801,6 +3812,58 @@ def _reconcile_blocked(
     """
     if is_permanent_block_reason(entry.last_reason):
         return None
+    if _is_unsatisfiable_prereq_reason(entry.last_reason):
+        # #2935: this entry's ONLY `blocked` cause is `_resolve_prereqs`'s
+        # own after= verdict (step 4's launch walk, or its #2362/#2756
+        # sibling `_reconcile_blocked_after`, called immediately before this
+        # function in the same per-tick loop) — a `waiting` entry that never
+        # reached `running` at all (see `_resolve_prereqs`'s own comment:
+        # "attempts is deliberately NOT incremented: nothing was ever
+        # launched for this entry"). A never-dispatched entry has no
+        # assignment and no branch, so there is no merge-queue row for
+        # #2230's gate sweep to have ANY opinion about — a merge gate cannot
+        # exist for something that was never built, and probing for one
+        # anyway is a category error, not a failed probe.
+        #
+        # This must be checked BEFORE `_blocked_gate_reading`/
+        # `_reconcile_blocked_unreadable` below, not folded into their "no
+        # evidence" handling: `_reconcile_blocked_unreadable` WRITES
+        # `last_reason` the instant the shell's live probe was attempted and
+        # came back with no key (`live_blocked_unreadable`) — and doing that
+        # here would CLOBBER this exact marker text, which is the ONLY
+        # signal `_reconcile_blocked_after` uses (both here and on every
+        # future tick) to recognise this row as an after=-caused block worth
+        # re-diagnosing at all. The claude-coordinator#2935 incident: five
+        # dependents whose prerequisite had already landed stayed `blocked`
+        # for 178-207 consecutive ticks apiece, because the FIRST tick after
+        # they became re-evaluable this way overwrote their own "will never
+        # satisfy"/"not queued, not merged and not open" text with this
+        # sweep's "no merge-queue row ... could not be read" sentence —
+        # after which `_reconcile_blocked_after`'s guard could never
+        # recognise the row again, even once the prerequisite genuinely
+        # landed. Bailing out here, before any write, keeps the marker
+        # intact for as many ticks as it takes the after= graph to actually
+        # clear — the entry's fate stays entirely `_reconcile_blocked_
+        # after`'s to decide, exactly as the issue's "Expected behaviour"
+        # asks: answered from the after= graph, never from a merge-gate
+        # probe.
+        #
+        # Deliberately a text match on the SAME two verdict shapes
+        # `_reconcile_blocked_after` itself already trusts to gate its own
+        # resume — not the #2589/#2635 per-run dispatch markers
+        # (`is_dispatch_failure_reason`/`is_empty_branch_death_reason`),
+        # which stay OUT of this function on purpose (see
+        # `test_a_pre_dispatch_reason_text_does_not_suppress_a_real_
+        # unreadable_note`): those two describe what ONE launch attempt
+        # dispatched, which can go stale the moment an earlier attempt on
+        # the SAME entry left real evidence behind, so only the shell's live
+        # re-check (`live_blocked_unreadable`) is trusted to suppress them.
+        # `_resolve_prereqs`'s unsatisfiable verdict carries no such
+        # per-run ambiguity: it is only ever written for a `waiting` entry
+        # that has NEVER reached `running`, so the "nothing was ever
+        # dispatched" reading it encodes cannot be contradicted by an
+        # earlier attempt the way a per-run marker can.
+        return None
     reading = _blocked_gate_reading(entry, facts, live_blocked_gate)
     if reading is None:
         return _reconcile_blocked_unreadable(entry, live_blocked_unreadable)

{code_coordinator-0.5.295 → code_coordinator-0.5.296}/tests/test_drive_queue.py

@@ -3355,6 +3355,105 @@ def test_a_blocked_entry_that_has_hit_the_resume_ceiling_stays_blocked_and_says_
     assert plan.launch is None
 
 
+# ── #2935: a never-dispatched after=-blocked entry must never reach the ────
+# merge-gate sweep at all
+#
+# claude-coordinator#2935: a `waiting` entry blocked by `_resolve_prereqs`'s
+# own unsatisfiable `after=` verdict has no assignment and no branch — there
+# is categorically no merge-queue row for #2230's sweep to have an opinion
+# about, "unreadable" or otherwise. Before this fix, `_reconcile_blocked`
+# never special-cased this shape: it fell through to `_blocked_gate_reading`
+# (which correctly finds no evidence) and then to `_reconcile_blocked_
+# unreadable`, which — whenever the shell's live probe had actually been
+# attempted (`live_blocked_unreadable` carrying a note, exactly what
+# `coord.commands.drive_queue._fetch_live_blocked_gate`'s #2806 self-heal
+# produces for a row with no merge-queue row) — WROTE `last_reason` to a
+# "could not be read" sentence. That overwrite destroyed the only marker
+# `_reconcile_blocked_after` uses to recognise this row as after=-caused at
+# all, so every later tick — even long after the prerequisite landed — took
+# the SAME "no evidence, probe unreadable" branch forever: a permanent
+# block, never resumed. These pin the fix: the merge-gate sweep must bail
+# out before ever consulting `live_blocked_unreadable` for this shape, and
+# the entry must still resume once its prereq actually lands.
+
+
+def test_a_never_dispatched_after_blocked_entry_never_reports_gate_unreadable():
+    """The shell's live probe (a real `live_blocked_unreadable` note, the
+    exact shape `_fetch_live_blocked_gate` emits for a row with no
+    merge-queue row) must not produce a `gate_unreadable` reconcile — or any
+    write at all — for an entry whose only cause is an unsatisfiable
+    `after=` verdict with its prereq still not landed."""
+    dep_key = entry_key(REPO, 2897)
+    entries = [
+        entry(2897, position=0, state=STATE_BLOCKED),
+        _blocked_entry(
+            2899,
+            position=1,
+            after=(dep_key,),
+            last_reason=f"pre-req {dep_key} is queued but blocked — it will never satisfy",
+        ),
+    ]
+    plan = plan_tick(
+        entries,
+        board(),
+        capacity=1,
+        live_blocked_gate={},
+        live_blocked_unreadable={
+            entry_key(REPO, 2899): "no merge-queue row for this entry, even "
+            "after the self-heal enqueue attempt"
+        },
+    )
+    assert plan.reconciles == ()
+    assert plan.launch is None
+
+
+def test_a_never_dispatched_after_blocked_entry_still_resumes_once_its_prereq_lands():
+    """End-to-end regression for the #2935 incident: a tick where the
+    prereq has NOT yet landed and the shell's probe comes back unreadable
+    must leave `last_reason` untouched (nothing in `plan.reconciles` to
+    write) — so a LATER tick, once the prereq lands, still recognises the
+    original marker and resumes normally, exactly as it would have if the
+    spurious probe had never run."""
+    dep_key = entry_key(REPO, 2897)
+    blocked_dep = entry(2897, position=0, state=STATE_BLOCKED)
+    dependent = _blocked_entry(
+        2899,
+        position=1,
+        after=(dep_key,),
+        resumes=0,
+        last_reason=f"pre-req {dep_key} is queued but blocked — it will never satisfy",
+    )
+
+    # Tick 1: prereq still blocked, shell's probe comes back unreadable —
+    # must be a total no-op (the #2935 fix).
+    tick1 = plan_tick(
+        [blocked_dep, dependent],
+        board(),
+        capacity=1,
+        live_blocked_gate={},
+        live_blocked_unreadable={
+            entry_key(REPO, 2899): "no merge-queue row for this entry, even "
+            "after the self-heal enqueue attempt"
+        },
+    )
+    assert tick1.reconciles == ()
+
+    # Tick 2: the prereq has since landed. `dependent`'s `last_reason` is
+    # STILL the original unsatisfiable-prereq marker — untouched by tick 1 —
+    # so `_reconcile_blocked_after` recognises it and resumes it, even
+    # though a merge-gate probe against it failed in between.
+    tick2 = plan_tick(
+        [entry(2897, position=0, state=STATE_DONE), dependent],
+        board(merged=(2897,)),
+        capacity=1,
+    )
+    reconcile = next(r for r in tick2.reconciles if r.key == entry_key(REPO, 2899))
+    assert reconcile.outcome == "resumed"
+    assert reconcile.updates["state"] == STATE_WAITING
+    assert reconcile.updates["attempts"] == 0
+    assert tick2.launch is not None and tick2.launch.issue == 2899
+
+
 # ── #2362: a blocked entry resumes once its unsatisfiable after= lands ─────
 #
 # `_resolve_prereqs` blocks a `waiting` entry the instant one of its named