Fix manual trace pcbPath handling for KiCad footprints #29
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (portsWithoutMatchedPcbPrimitive.length > 0) { | ||
| const awaitingFootprintLoad = portsWithoutMatchedPcbPrimitive.some((port) => { | ||
| const parent = port.parent as { _hasStartedFootprintUrlLoad?: boolean } | null | ||
| return parent?._hasStartedFootprintUrlLoad | ||
| }) | ||
|
|
||
| if (awaitingFootprintLoad) { | ||
| trace.renderPhaseStates.PcbManualTraceRender.dirty = true | ||
| return |
There was a problem hiding this comment.
The new early‐return in Trace_doInitialPcbManualTraceRender treats any unmatched port whose parent has _hasStartedFootprintUrlLoad set as “still loading” and skips the error insertion. When a footprint load ultimately fails (resolver rejects), that flag remains true but no pads are created, so this branch keeps marking the phase dirty and returning on each render. After the async effect completes, the render loop stops and the manual trace remains unrendered with no pcb_trace_error, hiding the failure that was previously surfaced. The code should distinguish between an in‑progress load and a completed/failed load before bypassing the error path.
Useful? React with 👍 / 👎.
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_68fbc5c75f5c8328b8b71ea474cd3261