I need to identify the SDK our script really imports. The old laptop runs our read-only FR5 status collection, but the rebuilt one rejects an argument before contacting the controller. Same script, several SDK folders, no imported-copy note. This is our fixture inspection station; where should I compare first?
Compare the running interpreter and loaded module path on both laptops. Folder names are not proof of what was imported. Save the exact argument error too, then compare the loaded method signatures rather than editing the script to fit whichever copy won.
The error is recorded and happens at the call. I can inspect the old laptop without changing it. Both machines have more than one SDK directory, so I will record what the running process loads.
Keep that pre-connection boundary clear in the ticket. There may be other problems later, but this argument rejection does not justify changing controller network settings. First establish which local interface the unchanged caller meets.
Good distinction. Record the actual launch route as well as an interactive check. A successful test under one interpreter doesn't explain a shortcut still selecting another one.
Normal launch is a shortcut. Loaded paths differ between the two laptops, and the method signatures differ too. I have not renamed the argument; I'm checking which supported package the rebuild was meant to use.
That sounds more useful than our usual folder-name debate. Can the person who rebuilt it identify the intended environment, or did they copy several versions over without selecting one?
Nina, even if the rebuild intention is unclear, the working laptop provides an observed configuration to investigate. I'd preserve that evidence before anyone cleans up directories on either machine.
Rebuilder confirms no SDK was selected in the handover. We are documenting the old working environment and asking support to confirm the intended supported setup before changing the shortcut. The unused folders are untouched.
Once agreed, make the launch choice explicit and repeat only the documented read-only call first. Passing local argument validation and receiving a usable controller response are separate checks; record both instead of one works tick.
And include response interpretation for the selected SDK. Fixing the signature mismatch can reveal a return-value difference that the old caller wasn't written to handle.
The selected environment is now documented and the shortcut uses it. Local argument rejection is gone. Maintenance will own the rebuild note; the controller response comparison is still pending, so I am not reporting the dashboard restored.
Only the rebuilder so far. I'll have maintenance check the ordinary launch and include the observed interpreter and imported path in that record. Thanks for catching the account assumption, Nora.
That also makes the handover test easy to describe: can the next person launch the identified environment without choosing among the copied folders? The pending response check can remain a separate item.
Leave the old working laptop unchanged until that comparison is complete. You have solved a specific local mismatch, not yet replaced all the evidence the old installation provides.