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

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

yeah not sure my core pr would've done that

need help debugging this ?

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

Yes

Im afk would appreciate help if possible

One sec

ok

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

This is likely the issue

ok

Tyty sry tyty

no worries

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.

reproed

and should be fixed in this PR <@757706909351411845>

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

Vased on your description that solution doesnt seem correct

I think the footprint circuit json should have annotation

Sorry for the delay

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)

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

will see

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

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

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

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

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

will this fix the issue ?

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

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

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"]}.

<@757706909351411845>

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 ```

Ohhh nice cool

Yea we should add pos/neg

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

Will do

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

<@756504518417711104>

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

<@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.

is this the right fix ?

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

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

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