Skip to content

srxsync: lock candidate config at connect() in rustez, matching PyEZ - #9

Merged
fastrevmd-lab merged 1 commit into
masterfrom
mec-980-align-candidate-lock-timing
Sep 30, 2026
Merged

fastrevmd-lab merged 1 commit into
masterfrom
mec-980-align-candidate-lock-timing

Conversation

@fastrevmd-lab

Copy link
Copy Markdown
Member

Summary

PyEZTransport takes the exclusive candidate lock in connect() and holds it until close(). RustezTransport deferred locking to the first load() call, which left a window on the push path (connect() → load()) where another session could mutate the candidate config while ours sat unlocked, and meant a read-only check (connect() + fetch(), no load()) never locked at all on rustez while it always locked on PyEZ (#7 documented this without fixing it).

This moves the rustez lock acquisition into connect() so both backends take and hold the lock at the same point in the session lifecycle. load() no longer lazily creates/locks the Config object — it uses the one set up in connect().

Changes

  • srxsync/transport/rustez.py: connect() now creates the Config and calls lock() right after Device.open(), setting self._locked = True. load() no longer lazily locks.
  • README.md: updated the "Locking differs between backends" note to describe the now-unified behavior.
  • Tests (one per backend, per the issue):
    • tests/unit/test_transport_pyez.py::test_connect_locks_before_any_read — asserts PyEZ's existing lock-in-connect() ordering (open, then lock) as a baseline/regression guard.
    • tests/unit/test_transport_rustez.py::test_connect_locks_immediately_like_pyez — asserts rustez now locks in connect() (fails against the old code, where connect() never touched Config).
    • tests/unit/test_transport_rustez.py::test_load_does_not_relock — asserts load() reuses the existing lock rather than calling lock() again.

Verification

.venv/bin/ruff check .                                    # All checks passed!
.venv/bin/mypy srxsync                                     # Success: no issues found in 19 source files
.venv/bin/python -m pytest tests/unit -q                   # 73 passed

No new dependencies. No live device access used — verified against fixtures/mocks per existing test patterns in tests/unit/test_transport_{pyez,rustez}.py.

Closes #8

🤖 Generated with Claude Code

rustez deferred the candidate lock to the first load(), while PyEZTransport
locks in connect() and holds it through close(). That left a window on the
push path (connect -> load) where another session could mutate the
candidate config unlocked, and made rustez's read-only `check` path never
lock at all while PyEZ's did.

Move the rustez lock into connect() so both backends take and hold the
lock at the same point in the session lifecycle. Adds a test per backend
covering the lock timing.

Closes #8

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@fastrevmd-lab
fastrevmd-lab merged commit 9f5a7f4 into master Sep 30, 2026
7 checks passed
@fastrevmd-lab
fastrevmd-lab deleted the mec-980-align-candidate-lock-timing branch September 30, 2026 05:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Transport backends lock the candidate config at different times (PyEZ at connect, rustez at load)

1 participant