target: roll back activation state on failed activation

[ozan956]

Target.activate() activates suppliers recursively before activating the requested client. If a later activation step fails, previously activated suppliers could remain active while the failed client stayed bound.

This could leave shared agents, USB interfaces, ports, locks, or other resources in a stale state and cause subsequent activation attempts to fail.

This issue was encountered while extending FT232H/FTDI GPIO support.

The FTDI driver acquires a shared agent before calling proxy.setup(). When setup fails, the driver must release the agent and restore the FTDI interface state itself. This driver-specific cleanup exposed a more general lifecycle problem in Target.activate().

[github-actions]

LLM review

This series fixes Target.activate() leaving the target in an inconsistent state when
activation fails partway through: fff0742 rolls back suppliers newly activated during a
failed attempt, and 2dc0fb7 additionally restores pre-existing clients that
resolve_conflicts() deactivated to make room for the new client.

Session: 33240410294

Analysis

No CI logs or PR discussion were available specific to this exact commit range (CI notes
input was empty). The PR discussion history does contain two earlier reviews of what is
functionally the same change under different commit hashes (b03ff48/2891648); both minor
issues raised there — raw-repr logging instead of .display_name, and a missing regression
test for the "restore failure preserves original exception" path — are already fixed in the
current fff0742/2dc0fb7.

Independently traced _activate()/activate()/deactivate() and reproduced two scenarios
beyond the existing tests:

• A 3-level supplier chain (resource -> intermediate driver -> top driver), all active
  before a conflicting failed activation: rollback and restore both happen in correct
  dependency order (suppliers before clients).
• An unrelated, previously-active resource/driver pair not involved in the conflict is left
  fully untouched by the rollback/restore logic that fixes up the actually-conflicting
  driver.

Restore ordering correctness relies on self.resources/self.drivers preserving
supplier-before-client order, which holds because bind_driver() requires suppliers to
already be bound (and thus already appended) before a client can bind.

No functional bug found; no fixup patches suggested.

CI warnings

CI notes for this run were empty, so no CI annotations could be reviewed.

Verification data

No datasheets/binary artifacts involved. Verification was code-only:

• pip install -e ., pip install psutil pytest-mock.
• python -m pytest tests/test_target.py -q — 46 passed.
• python -m pytest tests/ -q -k "not test_docker_with_daemon" — 454 passed, 62 skipped, 2
  pre-existing/unrelated errors in tests/test_pb2.py (missing pytest-benchmark).
• pylint labgrid/target.py — 10.00/10.
• Two standalone reproduction scripts covering multi-level restore ordering and
  non-interference with unrelated previously-active drivers.

Suggested patches

None. Both issues flagged in earlier review rounds of this change are already resolved in
the current commits.

Install instructions

The following one-liner installs the script if not present already:

curl -fSsL "https://raw.githubusercontent.com/analogdevicesinc/doctools/refs/heads/main/ci/scripts/apply-patches.sh"      -o ~/.local/bin/apply-patches.sh &&   grep -q "/apply-patches.sh" ~/.bashrc || echo "source ~/.local/bin/apply-patches.sh" >> $_ ; . $_

More information at AI Usage.