Repository navigation
Reciprocal blocked_by edits on different branches merge clean into a dependency cycle that default pm validate misses; pm next then silently returns nothing #610
Description
Summary
Two agents on separate branches each add a blocked_by on the other's item (independent edits to different files → no git conflict). The merge is clean, but it creates a dependency cycle (pm-A → pm-B → pm-A) that the default pm validate does not flag, and pm next then silently returns nothing — both items become permanently un-actionable while the merge gate stays green.
Verified repro (pm 2026.7.18; items pm-AAAA, pm-BBBB)
git checkout -b brC
pm update pm-AAAA --blocked-by pm-BBBB --author agentA --json >/dev/null
git add -A && git commit -m "C: A blocked_by B"
git checkout -b brD main
pm update pm-BBBB --blocked-by pm-AAAA --author agentB --json >/dev/null
git add -A && git commit -m "D: B blocked_by A"
git checkout brC && git merge --no-edit brD # CLEAN (rc=0)
pm validate --json # ok: true (cycle NOT caught)
pm validate --check-lifecycle --json # ok: true (default cycle severity = warn)
pm validate --check-lifecycle --dependency-cycle-severity error --json # ok: false (only this catches it)
pm next --json # no actionable item (silent dead-end)Impact
A cross-branch dependency cycle is a classic multi-agent merge hazard (each agent's edit is locally valid; only the combination is broken). It survives the default merge gate and quietly starves the ready-queue. An agent running pm validate && merge sees green and moves on; pm next later returns nothing with no explanation.
Suggested fixes
- Make dependency-cycle detection part of the default
pm validate(at minimum surfaced as an error in a--strict-exit/merge context), not gated behind--check-lifecycle --dependency-cycle-severity error. - Have
pm nextemit an explicitblocked_by_cyclereason (with the offending item ids) instead of returning an empty recommendation, so the dead-end is self-diagnosing.
Filed from a multi-agent merge stress test; reproduced independently on 2026.7.18.
Activity
coderabbitai commentedon Jul 18, 2026
🔗 Related PRs
#37 - Improve agent token UX and blocked dependency handling [closed]
#200 - Add validation self-repair and agent ergonomics primitives [closed]
#406 - feat(mcp): extension-aware built-in actions + action-scoped name schema (pm-zumn, pm-fq80) [merged]
#502 - Atomic agent work selection, dependency integrity, and recovery primitives [merged]
#545 - SDK contract integrity: workspace paths, dependency truth, validation, and MCP parity [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
unbraind commentedon Jul 19, 2026
Closing this as a duplicate of #590 (and the cycle-detection work in #271/#280, all completed) after a more precise re-test on pm 2026.7.18.
On re-verification, the tool actually handles the merge-created cycle acceptably, and my original claims were imprecise:
pm validatedoes NOT "miss" the cycle — it reports it in the lifecycle check:dependency_cycle_count: 1,dependency_cycle_item_count: 2, plusdependency_cycle_item_idsanddependency_cycle_sample_paths. It staysok:trueonly becausedependency_cycle_severity_policydefaults towarn.pm validate --strict-exitreturns rc=1 on the merged cycle — so a merge-safety gate that uses strict-exit (as it should) does catch it.pm validate --check-lifecycle --dependency-cycle-severity erroralso returnsok:false.pm nextis not silent — it returnsrecommended: nulland lists both items underblocked[].The only genuinely distinct angle vs #590 is that a cycle can be introduced by a clean
git merge(each branch adds one edge to a different item, so no single mutation sees both edges and #590's inline warning cannot fire). But the post-merge gate already exists (--strict-exit→ rc=1), so there is no un-addressed defect here. Closing to avoid duplicating the settled #590 decision. The genuinely novel merge findings from the same test are tracked separately in #608, #609, #611, #612.unbraind commentedon Jul 19, 2026
pm tracker item: pm-i6pi (closed as duplicate of GH-590; mutation-time ordering-cycle advisories shipped in PR#593 — merge-path residue tracked by the pm-g5sx merge-semantics family)
chore(pm): full-directive review 2026-07-19 — PR#593/#594/#605 lanes …