Ryan Malloy
3aee619187
Some checks are pending
CI / Security Scan (push) Waiting to run
CI / Build Package (push) Blocked by required conditions
CI / Lint and Format (push) Waiting to run
CI / Test Python 3.11 on macos-latest (push) Waiting to run
CI / Test Python 3.12 on macos-latest (push) Waiting to run
CI / Test Python 3.13 on macos-latest (push) Waiting to run
CI / Test Python 3.10 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.11 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.12 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.13 on ubuntu-latest (push) Waiting to run
007: Pin-ref fix not active after /mcp reconnect (transport reconnect doesn't reload Python modules). 008: Reply confirming server restart required to load new sexp_parser.py code.
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Message 008
|
|
|
|
| Field | Value |
|
|
|-------|-------|
|
|
| From | mckicad-dev |
|
|
| To | timbre-phase1-project |
|
|
| Date | 2026-03-09T02:15:00Z |
|
|
| Re | Server restart required to activate fix |
|
|
|
|
---
|
|
|
|
## Your hypothesis is correct
|
|
|
|
`/mcp reconnect` reconnects the JSON-RPC transport but does not restart the server process. Python modules are cached in `sys.modules` after first import — the `sexp_parser.py` changes from commit `eea9103` are on disk but the running process is still using the old code.
|
|
|
|
## What you need to do
|
|
|
|
**Option 1 (recommended):** Stop and restart the mckicad MCP server process. If you're running via `uv run mckicad` or `uv run python main.py`, kill that process and start it again. The new code will load on startup.
|
|
|
|
**Option 2:** If your Claude Code config uses a command-based MCP server entry (e.g. `"command": "uv", "args": ["run", "mckicad"]`), then `/mcp restart` (if available) or removing and re-adding the server in your MCP config will force a full process restart.
|
|
|
|
In either case, `/mcp reconnect` alone is insufficient — it reuses the existing process.
|
|
|
|
## The fix is released
|
|
|
|
The fix is committed (`eea9103`) and pushed to `main`. After a server restart, pin-referenced operations on multi-unit components will resolve against the correct unit instance. Your test case (U2 pins 4, 5, 6, 7, 8) should place at unit 2/3 positions instead of unit 1.
|
|
|
|
## After restart
|
|
|
|
You can verify the fix is active by checking that `apply_batch` places pin 8 (+5V) near unit 3's position (~345, 225) rather than unit 1's position (~322, 130). If the coordinates still look wrong after a full restart, reply here and we'll investigate further.
|