kafka-0009: GraphGraceSearchUtil diamond recursion O(2^D) → O(N); count 621→622
findAndVerifyWindowGrace() recurses over parent GraphNodes without a visited accumulator. Kafka Streams GraphNode is a genuine DAG (addChild wires parent→child with multiple parents allowed), so a diamond topology causes 2^D recursive calls. Fix: thread an IdentityHashMap<GraphNode,Long> memo through recursion; memoize on first visit, return cached result on revisit. 8/8 unit tests PASS; D=10 defect count=3071 vs patched O(N). Diamond-recursion CLEAN markers added for: flink, neo4j, janusgraph, tinkerpop, dgraph, zookeeper, storm, ant, gradle, graal, eclipse-jdt, exposed, intellij, kotlin, scala3, hibernate-0007 (prior session work now committed).
This commit is contained in:
parent
0c5788f7ac
commit
1dee074618
20 changed files with 977 additions and 1 deletions
19
defects/dgraph/patch/dgraph-diamond-recursion-CLEAN.md
Normal file
19
defects/dgraph/patch/dgraph-diamond-recursion-CLEAN.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
# dgraph — diamond recursion CWE-407 scan: CLEAN
|
||||
|
||||
## Scan date: 2026-03-29
|
||||
|
||||
## Method scanned
|
||||
|
||||
`SubGraph.recurse()` in `query/query.go` — recursive SubGraph traversal.
|
||||
|
||||
## Finding
|
||||
|
||||
`SubGraph.Children` and `SubGraph.Filters` are `[]*SubGraph` slices. Each SubGraph
|
||||
is created from a DQL parse tree where each child has a unique parent. The structure
|
||||
is a tree (parse tree), not a DAG. A single SubGraph node cannot appear as a child
|
||||
of two different parents, so diamond blowup is not possible.
|
||||
|
||||
The existing `dgraph-0001` (shortest-path route indexOf) was already filed. No new
|
||||
diamond recursion patterns were found.
|
||||
|
||||
## Verdict: CLEAN
|
||||
Loading…
Add table
Add a link
Reference in a new issue