blocks_add skips the cycle check that deps_add runs #822
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#822
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
deps_addrefuses an edge that would close a dependency cycle: it checks the new edge against the whole existing graph.blocks_addsends the edge straight to the forge with no check.The forge refuses only a cycle of two issues. A cycle of three or more is accepted, through both the dependencies and the blocks endpoint. The close-semantics probe in
internal/testforge/closeprobeshows this on Forgejo and Gitea, at the baseline and latest pins. Soblocks_addcan build a ring such as A -> B -> C -> A, and none of those issues can ever close.Fix:
blocks_addruns the same cycle check asdeps_addbefore it writes the edge, and refuses with the same message that names the cycle path.Acceptance, against throwaway Forgejo and Gitea servers:
blocks_addthat would close a ring of three issues is refused before any write, and the message names the ring.blocks_addthat closes no cycle still writes the edge.