dynamicAnchors (compilers/openapi/internal/schema/schema.go) reports whether the $dynamicAnchor index ran to completion as one bool:
return w.out, !w.truncated && !w.view.Exhausted()
AnchorIndex.sites then turns false into a single message:
the $dynamicAnchor index stopped at its walk bounds (512 levels, 1048576 nodes);
a $dynamicRef expanded below is not verified to name the document's only anchor of its name
But w.view.Exhausted() is set by a different bound: nodeview.MergeDepthLimit, the 64-level << merge-key expansion cap. A document whose merge chain is past that bound and whose walk never came near 512 levels or 2²⁰ nodes gets a warning naming two bounds it did not hit and omitting the one it did.
Reproducer
mergeBoundOrderSpec in compilers/openapi/internal/schema/schema_test.go — x-d13..x-d20 carry chains past the merge bound. Since #453, both declaration orders emit the warning above; the walk itself is nowhere near its own bounds.
Before #453 the same message was reachable by any document that declared a deep chain before the shallow one it rides on, so the fold predates that change.
Suggested
Have dynamicAnchors report which bound stopped it — its own walk bounds or the view's merge bound — and have sites name that one. diag.CycleScanFailed already says "stopped at its 64-level merge-key expansion bound" for the pre-parse scan's identical case, so the message for that arm can match it.
Found while fixing #404.
dynamicAnchors(compilers/openapi/internal/schema/schema.go) reports whether the$dynamicAnchorindex ran to completion as one bool:AnchorIndex.sitesthen turnsfalseinto a single message:But
w.view.Exhausted()is set by a different bound:nodeview.MergeDepthLimit, the 64-level<<merge-key expansion cap. A document whose merge chain is past that bound and whose walk never came near 512 levels or 2²⁰ nodes gets a warning naming two bounds it did not hit and omitting the one it did.Reproducer
mergeBoundOrderSpecincompilers/openapi/internal/schema/schema_test.go—x-d13..x-d20carry chains past the merge bound. Since #453, both declaration orders emit the warning above; the walk itself is nowhere near its own bounds.Before #453 the same message was reachable by any document that declared a deep chain before the shallow one it rides on, so the fold predates that change.
Suggested
Have
dynamicAnchorsreport which bound stopped it — its own walk bounds or the view's merge bound — and havesitesname that one.diag.CycleScanFailedalready says "stopped at its 64-level merge-key expansion bound" for the pre-parse scan's identical case, so the message for that arm can match it.Found while fixing #404.