Skip to content

fix(planner): Ignore has-many back-references in cycle detection - #100

Merged
mhiro2 merged 2 commits into
mainfrom
fix/hasmany-backref-cycle-detection
Oct 13, 2026
Merged

mhiro2 merged 2 commits into
mainfrom
fix/hasmany-backref-cycle-detection

Conversation

@mhiro2

@mhiro2 mhiro2 commented Oct 13, 2026

Copy link
Copy Markdown
Owner

Summary

  • Stop rejecting finite graphs that loop through a has-many parent, such as assignment -> employee -> department -> employees, as dependency cycles
  • Keep reporting genuinely infinite required recursion, including self and mutual has-many chains
  • Document how back-referenced has-many children are treated during cycle detection

Changes

  • 172f8e7 : fix(planner): ignore has-many back-references in cycle detection
    • Cycle detection now also compares which relations a frame resolves through a structural back-reference, so a generated has-many child bound to the parent that created it no longer matches the unbound frame that started the chain
    • Bound relations are compared by name rather than by node, so recursion that rebinds a fresh parent on every level is still reported as ErrCycleDetected
    • Planner and public API tests cover the finite back-reference graph and the required self and mutual has-many cycles
  • 8ead5bb : docs: describe back-reference handling in cycle detection
    • ARCHITECTURE.md and the guide explain that a has-many child bound back to its creating parent is not treated as a revisit

Cycle detection compared only the blueprint name and options, so a
finite graph such as employee -> department -> employees was rejected
because employee appeared twice on the expansion path even though the
generated employees bind their department relation to the department
that created them. The expansion stack now also records which
relations a frame resolves through a structural back-reference, so a
bound child no longer matches the unbound frame that started the
chain. Recursion that rebinds a fresh parent on every level, such as a
required self or mutual has-many, is still reported as a cycle.
Clarify that a has-many child bound back to the parent that created it
is not treated as a revisit, so belongs-to chains that loop through a
has-many parent expand finitely.
@mhiro2 mhiro2 self-assigned this Oct 13, 2026
@mhiro2 mhiro2 added the bug Something isn't working label Oct 13, 2026
@github-actions

Copy link
Copy Markdown

Code Metrics Report

main (4880ed2) #100 (7d6472e) +/-
Coverage 86.7% 86.8% +0.0%
Code to Test Ratio 1:0.9 1:0.9 +0.0
Test Execution Time 48s 1m17s +29s
Details
  |                     | main (4880ed2) | #100 (7d6472e) |  +/-  |
  |---------------------|----------------|----------------|-------|
+ | Coverage            |          86.7% |          86.8% | +0.0% |
  |   Files             |             59 |             59 |     0 |
  |   Lines             |           4771 |           4772 |    +1 |
+ |   Covered           |           4139 |           4143 |    +4 |
+ | Code to Test Ratio  |          1:0.9 |          1:0.9 |  +0.0 |
  |   Code              |          17736 |          17740 |    +4 |
+ |   Test              |          17596 |          17715 |  +119 |
- | Test Execution Time |            48s |          1m17s |  +29s |

Code coverage of files in pull request scope (83.2% → 84.6%, patch 100.0%)

Files Coverage +/- Patch Coverage Status
internal/planner/expand.go 92.8% +0.2% 100.0% modified
internal/planner/expand_relations.go 83.5% +1.5% - affected

Reported by octocov

@mhiro2
mhiro2 merged commit 96cd3f6 into main Oct 13, 2026
11 checks passed
@mhiro2
mhiro2 deleted the fix/hasmany-backref-cycle-detection branch October 13, 2026 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant