Arhan - I’m recreating the Adafruit Feather RP2...

I don't think it's an autorouter error, it's a type error

It should be simple to figure out the type you are using incorrectly

I traced the TypeError to the USB-C component having missing PCB ports after its standard footprint fetch failed. Is it expected behavior for an incomplete/missing footprint to crash with `connectedPort.x`?

If the fetch failed then autorouting should be blocked

I verified this in `core`. The existing USB-C fetch-failure test confirms that a failed standard-footprint fetch can leave the connector with logical ports but zero PCB pads: ```ts expect(circuit.db.pcb_smtpad.list()).toHaveLength(0) ``` From: `tests/repros/repro-usbc-parts-engine-failure-empty-schematic.test.tsx` In `lib/utils/autorouting/getSimpleRouteJsonFromCircuitJson.ts`, the autorouting path maps source ports to PCB ports and filters only `null` values: ```ts const connectedPcbPorts = trace.connected_source_port_ids .map((sourcePortId) => db.pcb_port.getWhere({ source_port_id: sourcePortId })) .filter((pcbPort) => pcbPort !== null) ``` It then accesses: ```ts for (const connectedPort of connectedPcbPorts) { if (connectedPort.x === undefined || connectedPort.y === undefined) { // ... } } ``` When the PCB port is missing, the property access itself throws: ```text TypeError: undefined is not an object (evaluating 'connectedPort.x') ``` Would a failed footprint fetch be expected to block autorouting with a clear error, rather than allowing autorouting to crash?

block routing, show error