Summary
TopologyMergingSolver throws node "cmn_0" in group "global" has invalid bounds when a global capacity-mesh node produced by the upstream topology-planning stage has degenerate (zero/near-zero area) bounds. In production runframe sessions this aborts the whole autorouting pipeline and leaves the PCB preview empty, and the same error is re-thrown on every render attempt (observed firing dozens of times in a single session).
Where it throws
lib/solvers/TopologyMergingSolver/topology-merging-input.ts (validateTopologyMergingNode):
TopologyMergingSolver: node "cmn_0" in group "global" has invalid bounds
isValidCapacityBounds rejects the node because its width or height is <= GEOMETRY_EPSILON (or non-finite). The offending node is part of topologyOutput.globalMeshNodes, so the degenerate geometry originates upstream in the global mesh / topology-planning stage rather than in the merging solver itself.
Observed with @tscircuit/capacity-autorouter@0.0.665; the throw is unchanged on main.
Why not just swallow it
The repo's AGENTS.md "Fallback Logic" policy is explicit that a solver should fix the root cause or throw, not silently drop bad input and continue (that yields a "plausible-looking wrong route"). So the fix should be in whatever produces a zero-area global node, not a filter in the merging solver. Filing this so the root cause can be found with a proper reproduction.
What's needed
- A minimal circuit /
SimpleRouteJson that reproduces a zero-area global mesh node reaching TopologyMergingSolver.
- Fix the upstream stage so it never emits a degenerate global node (or, if a zero-area node is ever legitimate, decide the correct policy explicitly).
Related
The fact that this bubbled up as a repeated JS exception on the runframe side (rather than being shown as an autorouting failure) is being addressed separately in runframe.
Summary
TopologyMergingSolverthrowsnode "cmn_0" in group "global" has invalid boundswhen aglobalcapacity-mesh node produced by the upstream topology-planning stage has degenerate (zero/near-zero area) bounds. In productionrunframesessions this aborts the whole autorouting pipeline and leaves the PCB preview empty, and the same error is re-thrown on every render attempt (observed firing dozens of times in a single session).Where it throws
lib/solvers/TopologyMergingSolver/topology-merging-input.ts(validateTopologyMergingNode):isValidCapacityBoundsrejects the node because its width or height is<= GEOMETRY_EPSILON(or non-finite). The offending node is part oftopologyOutput.globalMeshNodes, so the degenerate geometry originates upstream in the global mesh / topology-planning stage rather than in the merging solver itself.Observed with
@tscircuit/capacity-autorouter@0.0.665; the throw is unchanged onmain.Why not just swallow it
The repo's
AGENTS.md"Fallback Logic" policy is explicit that a solver should fix the root cause or throw, not silently drop bad input and continue (that yields a "plausible-looking wrong route"). So the fix should be in whatever produces a zero-areaglobalnode, not a filter in the merging solver. Filing this so the root cause can be found with a proper reproduction.What's needed
SimpleRouteJsonthat reproduces a zero-areaglobalmesh node reachingTopologyMergingSolver.Related
The fact that this bubbled up as a repeated JS exception on the
runframeside (rather than being shown as an autorouting failure) is being addressed separately inrunframe.