Skip to content

Prevent explicit netlabels from expanding into long schematic traces#685

Open
rushabhcodes wants to merge 4 commits into
mainfrom
fix/explicit-netlabels-long-schematic-traces
Open

Prevent explicit netlabels from expanding into long schematic traces#685
rushabhcodes wants to merge 4 commits into
mainfrom
fix/explicit-netlabels-long-schematic-traces

Conversation

@rushabhcodes

@rushabhcodes rushabhcodes commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Summary

  • add preExistingNetLabelPinIds to the schematic trace solver input
  • prevent the long-distance fallback from routing across endpoints that already have user-placed netlabels
  • skip duplicate automatic label placement for pins and routed islands already represented by explicit netlabels
  • preserve existing long-distance routing for connections without explicit labels

Root cause

Normal MSP routing correctly rejects these connections because they exceed maxMspPairDistance. The long-distance fallback then reconnects the same endpoints with full-width schematic traces because it has no knowledge that one side is already represented by an explicit netlabel. Automatic netlabels are added later, but the unnecessary routes remain.

The new input field carries that intent into the solver. Long-distance candidates touching an explicitly labeled pin remain separate net islands, allowing the remaining endpoints to terminate at automatic netlabels without drawing wires across the schematic.

Cross-repository reproduction

The user-facing regression is reproduced in tscircuit/core#2725.

This PR also includes a minimal solver-level regression test and verifies that unlabeled endpoints still retain clear long-distance routes.

Before and after

Before After
Before: full-width traces are routed between explicitly labeled nets After: endpoints terminate at netlabels without full-width traces

The dashed lines are connectivity guides in the solver visualization. The solid full-width routes visible before the fix are no longer emitted afterward.

Validation

  • bun test tests/repros/repro152-explicit-netlabels-long-traces.test.ts tests/solvers/SchematicTracePipelineSolver tests/solvers/MspConnectionPairSolver tests/solvers/NetLabelPlacementSolver
  • bunx tsc --noEmit
  • normalized final-routing snapshot verification

@vercel

vercel Bot commented Jul 19, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
schematic-trace-solver Ready Ready Preview, Comment Jul 19, 2026 8:31pm

Request Review

@rushabhcodes
rushabhcodes marked this pull request as ready for review July 20, 2026 07:52
Copilot AI review requested due to automatic review settings July 20, 2026 07:52

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@MustafaMulla29 MustafaMulla29 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The repro you merged was with manual netlabels and trace solver doesn't know about manual netlabels. I think auto netlabels won't have the same outcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants