ngx-json-render 0.4.0 decides recursion with a prefix test on the resolved state path

The two specs at issue differ by one path expression. In the recursive tree, the `kids` element repeats over `{ "$item": "children" }` ^[6]. That path is relative: it resolves against the item the repeat is already inside, so each pass reads one level further into the data and the recursion ends where the data does ^[7]. In the permutation spec, `node` repeats over the absolute `/items` and lists itself as its only child, so every level re-reads the same eight-item array ^[9]. According to the ngx-json-render post, models produce this shape when they mean to recurse and reach for the absolute path they already used ^[10].

The ancestry question fails here. `kids` is its own ancestor by design, so the textbook check that carries ancestry down the render and refuses any element that is its own ancestor throws out the comment thread along with the crash ^[5][6]. The author's earlier article had listed maximum graph depth, maximum rendered nodes and explicit cycle protection as the work remaining. "Building it turned out to be a lesson in how many wrong answers look right," the author wrote ^[17].

The next answer compares the element key together with its repeat scope, allowing an element inside itself as long as each pass renders a different item ^[8]. The tree passes. So does the nine-line permutation spec, because item 3 inside item 1 inside item 5 repeats no item along the path ^[9]. No item may appear twice on a path, so depth stops at eight and every path is a sequence of distinct items. Full-depth paths alone number 8! = 40,320 ^[1], and adding every shallower level gives 109,600 boxes ^[2]. The post reports that those nine lines produce tens of thousands of boxes without crashing, and calls it a bounded denial of service against the tab ^[9][11].

Version 0.4.0 tests something else, whether the inner pass descended into the data ^[12]. The renderer walks up from the current render path to the nearest ancestor carrying the same element key, then checks whether the inner resolved scope path starts with the outer scope path plus a slash ^[13][14]. A sibling move from `/items/0` to `/items/1` fails that check. A move from `/tree/0` to `/tree/0/children/1` passes. A pass with no repeat scope at all, which is the two-element cycle, fails ^[12][13]. The trailing slash matters: without it, `/tree/10` would count as a step inside `/tree/1` ^[15].

The 143 is a property of that runtime's stack. Two elements in a cycle means roughly 71 round trips through `a` and `b` before the frames ran out ^[3]. For the figure to transfer you would need the same per-element frame cost, a renderer that walks children recursively the same way, and nothing else deep on the stack when the spec arrives; the post does not name the browser or version ^[2].

The descent test covers explicit cycle protection. With the rule in place the recursive tree renders in full ^[16], and a spec that descends correctly into deep data still renders one node per row it finds. Maximum graph depth and maximum rendered node count stay separate limits on the author's own list ^[17].