fix: keep graph-backend plans acyclic - #62
Conversation
|
Warning Review limit reachedNext included review available in 23 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis change prevents graph-based partitioning and minimum-size repair from creating circular merge dependencies, then validates the completed plan before returning it. The previously cycle-prone multi-file/multi-hunk behavior was exercised through the public partitioning interface, along with a real minimum-size repair merge and 80 deterministic inputs; every emitted plan had a valid merge order. Confidence Score: 5/5Safe to merge: exercised graph-partition plans remained acyclic across the historical reproduction, repair behavior, and deterministic multi-file inputs. No actionable defects remain after executing the focused partitioning checks. The test source and captured results show that the exercised failure path now produces valid plans. Files Needing Attention: No files need follow-up changes.
What T-Rex did
Reviews (1): Last reviewed commit: "fix: keep graph-backend plans acyclic" | Re-trigger Greptile |
The greedy grouper could put file A's earlier hunk and file B's later hunk in one group and the reverse in another; the file-order dependency derivation then produced a cycle, which surfaced later as a raw graphlib.CycleError traceback from score_plan. - _merge_order_is_acyclic mirrors _derive_merge_order_dependencies and is consulted before accepting a candidate in _group_units_graph (only when the candidate's file already appears in a finished group) and before accepting a min_loc merge in _best_graph_merge_target. - partition_diff validates the final DAG so any backend that still produces a cycle raises PlanValidationError(CYCLE_DETECTED) instead of a traceback. Fuzzing 800 random diffs across both priorities and min_loc settings produced 0 cyclic plans (1/400 before).
d64fdb8 to
00d9c05
Compare
Problem
The
graphpartition backend could emit a plan with a dependency cycle. The greedy grouper (_group_units_graph) may put file A's earlier hunk and file B's later hunk in one group and the reverse in another;_derive_merge_order_dependenciesthen produces e.g.Nothing in
partition_diffchecks for this, andscore_plan(called byplan_splitbeforevalidate_planever runs) then crashes with a rawgraphlib.CycleErrortraceback. Found by fuzzing: 1 in 400 random diffs with--priority logical.Fix
_merge_order_is_acyclic(grouped_units)mirrors the dependency derivation (per-file order by earliest unit) and checks it withgraphlib._group_units_graphrejects a candidate that would create a cycle. The check only runs when the candidate's file already appears in a finished group, since that is the only way a new edge is introduced._best_graph_merge_targetrejects a min_loc merge that would create a cycle.partition_diffvalidates the final DAG as a backstop, so a backend that still yields a cycle raisesPlanValidationError(CYCLE_DETECTED)instead of a traceback.Verification
min_loc).