# Seve - @Abse i'm seeing source errors now- is t...

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1523406557663072566
Started: 2026-07-05T19:13:47.460000+00:00
Last activity: 2026-07-08T23:56:27.401000+00:00

## Seve — 2026-07-05T19:13:46.872000+00:00

<@398467566588264449> i'm seeing source errors now- is this due to the core update 🤔
Attachment: image.png — https://community.tscircuit.com/media/1523406557285715998

## Seve — 2026-07-05T19:14:24.792000+00:00

there is new resolution for imported diodes, i wonder if the implementation was bad

## Abse — 2026-07-05T19:15:54.504000+00:00

yeah not sure my core pr would've done that

## Abse — 2026-07-05T19:16:58.803000+00:00

need help debugging this ?

## Abse — 2026-07-05T19:17:13.803000+00:00

can you point the pr that is sus to be the resone

## Seve — 2026-07-05T19:17:42.411000+00:00

Yes

## Seve — 2026-07-05T19:17:50.659000+00:00

Im afk would appreciate help if possible

## Seve — 2026-07-05T19:17:52.948000+00:00

One sec

## Abse — 2026-07-05T19:18:34.490000+00:00

ok

## Seve — 2026-07-05T19:18:48.959000+00:00

https://github.com/tscircuit/core/pull/2569

## Seve — 2026-07-05T19:18:56.371000+00:00

This is likely the issue

## Abse — 2026-07-05T19:19:20.760000+00:00

ok

## Seve — 2026-07-05T19:19:28.244000+00:00

Tyty sry tyty

## Abse — 2026-07-05T19:20:18.358000+00:00

no worries

## Abse — 2026-07-05T19:44:18.504000+00:00

The bug was that after PR #2569, diodes waited for footprint pin labels so polarity-aware footprints could override pin1/pin2. That part was good.
But for generic external footprints, the loaded footprint only had pin1 and pin2, with no anode or cathode labels. Core still treated that as “the footprint handles labels,” so it removed the diode’s default polarity aliases. Then normal traces like .D1 > .cathode stopped resolving and routing failed.

## Abse — 2026-07-05T19:45:46.812000+00:00

reproed
Attachment: image.png — https://community.tscircuit.com/media/1523414610269704242

## Abse — 2026-07-05T19:45:57.443000+00:00

and should be fixed in this PR <@757706909351411845>

## Abse — 2026-07-05T19:46:20.119000+00:00

https://github.com/tscircuit/core/pull/2583

## Seve — 2026-07-05T20:16:27.811000+00:00

Vased on your description that solution doesnt seem correct

## Seve — 2026-07-05T20:16:37.655000+00:00

I think the footprint circuit json should have annotation

## Seve — 2026-07-05T20:18:24.182000+00:00

Sorry for the delay

## Seve — 2026-07-05T20:20:42.138000+00:00

Can you see if we can attach appropriate metadata to footprints loaded outside of core- i think your code incorrectly infers anode based on pin number when footprints are specified aynchronously- which is definitely a weird behavior (it was our previous behavior)

## Seve — 2026-07-05T20:21:17.393000+00:00

I think we’re basically discovering that we need more jlc metadata to infer footprint pin labels for diodes

## Abse — 2026-07-05T20:34:33.771000+00:00

will see

## Abse — 2026-07-05T20:37:10.167000+00:00

but doesn't that mean we don't have a full safe if no pin label is provided?

## Seve — 2026-07-05T21:53:58.561000+00:00

We shouldnt keep assuming the pin labels if the circuit json given to us doesnt have it

## Seve — 2026-07-05T21:54:13.288000+00:00

You could add diodes as a special case for this- that would be fine

## Seve — 2026-07-05T21:55:10.821000+00:00

But your logic is based on whether or not the footprint is loaded asynchronously

## Abse — 2026-07-05T21:55:26.847000+00:00

<@757706909351411845> https://github.com/tscircuit/easyeda-converter/pull/403

## Abse — 2026-07-05T21:55:53.462000+00:00

will this fix the issue ?

## Seve — 2026-07-05T22:00:31.275000+00:00

That is the idea but how are you confirming correctness? It looks like you’re saying that pin1 is always anode?

## Seve — 2026-07-05T22:01:00.648000+00:00

Do they supply metadata- i perhaps in the schematic representation?

## Abse — 2026-07-05T22:38:34.619000+00:00

Correctness is coming from the EasyEDA schematic pin metadata, not from assuming pin1.
For the two diode fixtures:
```C57759:
pin1 -> ["C"]  // cathode
pin2 -> ["A"]  // anode

C2828420:
pin1 -> ["K"]  // cathode
pin2 -> ["A"]  // anode
```
So no, I’m not confirming by saying “pin1 is always anode”. It is actually the opposite in both checked examples: pin1 is cathode.

Where the metadata comes from:

EasyEDA stores schematic pins in dataStr.shape as P~... records.
The converter parses those into source_port elements.
Those source_port.port_hints carry labels like A, C, K.
Then we normalize:A, anode, pos, + -> anode
C, K, cathode, neg, - -> cathode

We attach that label to the same physical pin number.
So the generated mapping for these parts is:
```
const pinLabels = {
  pin1: ["cathode"],
  pin2: ["anode"],
} as const
```
And the footprint pads keep physical numbering, e.g. portHints={["pin1", "cathode"]}.

## Abse — 2026-07-05T22:41:52.617000+00:00

<@757706909351411845>

## Abse — 2026-07-05T22:46:28.694000+00:00

we do something like this
```const anodePin = labelsByPin.find(({ labels }) =>
  labels.some((label) => ["a", "anode", "pos", "+"].includes(label)),
)?.pin

const cathodePin = labelsByPin.find(({ labels }) =>
  labels.some((label) => ["c", "k", "cathode", "neg", "-"].includes(label)),
)?.pin
```

## Seve — 2026-07-06T04:46:45.150000+00:00

Ohhh nice cool

## Seve — 2026-07-06T04:46:53.032000+00:00

Yea we should add pos/neg

## Seve — 2026-07-06T04:47:05.697000+00:00

Sorry for the slow response!!!!!! Tyty!

## Abse — 2026-07-06T08:03:23.965000+00:00

Will do

## Abse — 2026-07-07T23:37:52.335000+00:00

<@757706909351411845> https://github.com/tscircuit/check-shorts/pull/6

## Abse — 2026-07-07T23:38:01.595000+00:00

<@756504518417711104>

## Abse — 2026-07-08T14:00:41.693000+00:00

<@757706909351411845> https://github.com/tscircuit/check-shorts/pull/7

## Abse — 2026-07-08T14:29:58.014000+00:00

<@757706909351411845> https://github.com/tscircuit/core/pull/2617

there was a bug where led symbol was messing 

The LED symbol was missing because the schematic symbol metadata was getting attached to the wrong Port instance.
For custom footprint LEDs, the flow is:
The footprint creates real child ports like pin1/A and pin2/K.
Later, initPorts() tries to attach the LED symbol’s schematic port definitions to matching pins.
The old code looked at newly-created ports first.
But when those duplicate same-pin ports were added, NormalComponent.add() skipped them because the real footprint ports already existed.
Result: the real A/K ports had no schematicSymbolPortDef, so SchematicPortRender skipped them, and the SVG renderer showed Could not match ports for symbol led_right.
The fix was in [NormalComponent.ts (line 387)](/Users/abdolsalamallawlabi/core/lib/components/base-components/NormalComponent/NormalComponent.ts:387): when matching symbol ports by pin number, it now checks existing child ports first, then falls back to newly-created ports.

## Abse — 2026-07-08T14:30:15.727000+00:00

is this the right fix ?

## Abse — 2026-07-08T14:37:43.370000+00:00

this happened on my PR only fyi ( not an old bug)

## Seve — 2026-07-08T14:38:55.427000+00:00

I think your pr is right it uses the same logic as diode

## Abse — 2026-07-08T23:56:27.401000+00:00

<@757706909351411845> https://github.com/tscircuit/cli/pull/3587