fix(eload): cache mode only after the driver confirms set_mode - #485

Summary

InstroELoad.set_mode() assigned self._mode = mode before it entered self._resource_lock and called self._driver.set_mode(...) (instro/eload/eload.py:224 on main). If the driver raised, for example a model that answers CP with NotImplementedError, the exception propagated but the cached mode was already updated to a mode the instrument was never put into. The next set_level() or set_range() then sailed past the "Mode must be set" guard and handed that wrong mode to the driver, so the load was driven in CP units while it was still in whatever mode it was actually in.

open() already resets self._mode = None when _apply_load_config() fails, so the config-driven path was covered. Direct set_mode() calls had no recovery, and the stale value persisted silently.

The fix moves the assignment inside the lock, after self._driver.set_mode(...) returns. InstroDMM already does it this way: every one of its setters calls the driver first and only then updates self._measurement_config (instro/dmm/dmm.py:292-365). ELoad was the outlier.

Fixes #417

Type of change

• Bug fix (fix)
• New feature (feat)
• Breaking change (feat! / fix!)
• Refactor (refactor)
• Documentation (docs)
• Chore / tooling (chore)

Verification

The new test fails on main and passes with the fix. Checking out just the unmodified module under the new test:

$ git checkout origin/main -- instro/eload/eload.py
$ uv run --frozen pytest -q tests/eload/test_eload_drivers.py::test_nominal_eload_set_mode_leaves_mode_unset_when_driver_raises
E       Failed: DID NOT RAISE ValueError
1 failed in 0.40s

With the fix in place:

$ uv run --frozen pytest -q tests/eload/test_eload_drivers.py::test_nominal_eload_set_mode_leaves_mode_unset_when_driver_raises
1 passed in 0.26s
$ uv run --frozen pytest -q tests/eload
56 passed, 2 deselected in 0.51s
$ uv run --frozen pytest -q
2235 passed, 2 skipped, 490 deselected, 1 xfailed in 17.99s
$ uv run --frozen ruff format --check
305 files already formatted
$ uv run --frozen ruff check
All checks passed!
$ uv run --frozen mypy
Success: no issues found in 85 source files

main at b8f262a gives 2234 passed on the same suite, so the only difference is the added test. The change is pure Python and touches no Rust, so I ran the Python half of just check and just test rather than the full native build. No hardware was used; the test drives a MagicMock(spec=ELoadDriverBase) the same way the surrounding InstroELoad tests do.

Tests

• Unit tests added or updated
• Existing tests cover this change
• No tests, explain why:

Checklist

• PR title follows Conventional Commits (e.g. feat(driver): add support for Keysight E36300)
• I have read CONTRIBUTING.md
• Documentation updated if user-facing behavior changed
• Code follows the style/conventions of the surrounding code

Notes for reviewers

No docs change: docs/guides/instrumentation/eload.mdx already says the mode must be set before level or range, and this only makes the code hold to that when the driver rejects the mode.

I left the self._mode = None rollback in open() alone. It still earns its place, because _apply_load_config() can fail at set_range or set_level after set_mode legitimately succeeded, and the cache has to be cleared for that case too.

Scoped to #417 only. #416, the atomicity of _apply_load_config across separately locked setters, is untouched here: the assignment now sits inside _resource_lock, which is where #416 would want it, so that work can build on this rather than undo it.