build(tesla): bump tesla-protocol floor to >=1.4.0 for protobuf 7 support - #140
Merged
Conversation
tesla-protocol 1.4.0 declares protobuf>=6.32.0,<8, unblocking dependents that need to move to protobuf 7 (Home Assistant's protobuf pin included). The proto bump renamed NavigationSuperchargerRequest.order to remote_nav_trip_order and added four new GetVehicleData substates (vehicle_config, soh_state, vehicle_detail_state, display_state), now wrapped as BLE readers; a fifth (getLegacyVehicleState) is allowlisted pending live verification of how it differs from the existing legacy_vehicle_state() reader. Version bumped to 1.12.1 per the repo's dependency-widening convention.
…stale AGENTS.md protocol-floor note
…w BLE reader test file
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
Prepare the release of tesla-fleet-api carrying the protobuf-7-compatible tesla-protocol dependency. Raise the tesla-protocol floor to >=1.4.0 in pyproject.toml (tesla-protocol 1.4.0 declares protobuf>=6.32.0,<8, protobuf 7 compatible; this repo's protobuf>=6.32.0 floor is already unbounded above and stays as-is). Regenerate uv.lock so its root package version and tesla-protocol pin match. Ran the full test suite against tesla-protocol 1.4.0: 749 passed. Additionally spot-checked the test suite with protobuf 7.36.0 installed: 749 passed too, proving the protobuf-7 combination works, then restored the locked (protobuf 6.33.6) environment for the committed state. Bumped the package version (pyproject.toml version and tesla_fleet_api/init.py version) from 1.12.0 to 1.12.1 per the repo's own convention for a dependency-widening release (matching recent patch-bump release history). Fixed test breakage caused by the tesla-protocol 0.5.0 -> 1.4.0 jump: a protobuf field rename (NavigationSuperchargerRequest.order -> remote_nav_trip_order) required updating tesla_fleet_api/tesla/vehicle/commands.py's navigation_sc_request and its test; and new GetVehicleData substate fields caught by tests/test_proto_coverage_lock.py's coverage-lock test were resolved by wrapping four of them (vehicle_config, soh_state, vehicle_detail_state, display_state) as new BLE reader methods on VehicleBluetooth in tesla_fleet_api/tesla/vehicle/bluetooth.py following the existing reader pattern (e.g. alert_state()/parked_accessory_state()), while getLegacyVehicleState was added to the test's allowlist with a reason (ambiguous versus the existing legacy_vehicle_state()/getVehicleState reader, pending live verification) rather than wrapped. Updated docs/bluetooth_vehicles.md's BLE state reader list to include the four new readers, and AGENTS.md's cross-transport-parity note to reflect that navigation_sc_request's id param is no longer proto-absent (the proto gained an id field alongside the rename), just unwired. Deliver as a PR; do not push a release tag - intended tag is v1.12.1, stated in the PR description.
What Changed
tesla-protocoldependency floor to>=1.4.0inpyproject.toml(from>=0.5.0) and regenerateduv.lock; bumped the package version from1.12.0to1.12.1inpyproject.tomlandtesla_fleet_api/__init__.py.tesla_fleet_api/tesla/vehicle/commands.py'snavigation_sc_request(NavigationSuperchargerRequest.order→remote_nav_trip_order) and updated the corresponding test intests/test_ble_nav_misc_commands.py.GetVehicleDatasubstate fields asVehicleBluetoothBLE reader methods (vehicle_config,soh_state,vehicle_detail_state,display_state) intesla_fleet_api/tesla/vehicle/bluetooth.py, following the existing reader pattern, with matching coverage added totests/test_ble_mocked_state_readers_new.py; addedgetLegacyVehicleStatetotests/test_proto_coverage_lock.py's allowlist with a documented reason (ambiguous versus the existinglegacy_vehicle_state()/getVehicleStatereader).docs/bluetooth_vehicles.md's BLE state reader list to include the four new readers, andAGENTS.md's cross-transport-parity note to reflect thatnavigation_sc_request'sidparam is now proto-present but unwired (no longer proto-absent).Intended release tag:
v1.12.1(not pushed by this PR).Risk Assessment
✅ Low: The fix round correctly resolved both prior findings with genuine behavioral tests (verified against actual tesla_protocol field names) and a stale-doc update, matches the stated user intent (floor bump, version bump, field rename fix, four new BLE readers, coverage-lock allowlist, docs), and introduces no new issues.
Testing
Ran the targeted BLE/proto-coverage/cross-transport-parity tests plus a broader BLE-keyword sweep (431 total test cases across the two runs), all passing under the locked tesla-protocol==1.4.0/protobuf==6.33.6 environment; confirmed uv.lock/pyproject.toml/version-string consistency and that both previously-requested review fixes (new BLE reader tests, AGENTS.md floor note) are correctly present in the diff. No issues found.
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
🔧 **Review** - 2 issues found → auto-fixed ✅
tesla_fleet_api/tesla/vehicle/bluetooth.py:1957- The four new BLE reader methods (vehicle_config, soh_state, vehicle_detail_state, display_state) added to VehicleBluetooth have no behavioral test exercising them end-to-end. Sibling readers added under the same pattern (alert_state, parked_accessory_state) have dedicated tests in tests/test_ble_mocked_state_readers_new.py that build a VehicleData reply and assert the decoded result; these four have none — grepping the test suite for calls to any of the four methods returns nothing. The only thing that currently 'sees' them is tests/test_proto_coverage_lock.py's coverage-lock check, which just does a source-string match (field.name/type_name in BLUETOOTH_SOURCE) and cannot catch a wrong field wiring, since a typo'd reply-field access would still satisfy that check as long as the method text mentions the right names. Verified the field names used (vehicle_config/soh_state/vehicle_detail_state/display_state) do match VehicleData's actual descriptor fields, so there's no live bug today, but the new public surface ships with zero functional test coverage protecting it going forward.AGENTS.md:112- AGENTS.md line 112 ('Keep the tesla-protocol floor at >=0.5.0; earlier releases have generated .pyi imports that are incompatible with this repository's strict pyright checks.') was not updated even though this change raises the actual floor in pyproject.toml to >=1.4.0. The statement isn't factually contradicted (>=1.4.0 still satisfies >=0.5.0), but it's now stale guidance that undersells the current requirement and doesn't mention the protobuf-7/gencode-compatibility reason for the new floor documented elsewhere in this same PR (the Runtime-version pin paragraph two lines above it).🔧 Fix: Add behavioral tests for 4 new BLE readers; fix stale AGENTS.md protocol-floor note
✅ Re-checked - no issues remain.
✅ **Test** - passed
✅ No issues found.
uv sync --locked(confirms uv.lock matches pyproject.toml's tesla-protocol>=1.4.0 floor and version 1.12.1)uv run pytest tests/test_ble_mocked_state_readers_new.py tests/test_ble_nav_misc_commands.py tests/test_proto_coverage_lock.py tests/test_cross_transport_parity.py -v(37 passed) — exercises the 4 new BLE readers (vehicle_config, soh_state, vehicle_detail_state, display_state), the navigation_sc_request order->remote_nav_trip_order field rename, and the GetVehicleData coverage-lock allowlist updateuv run pytest tests/ -k 'ble or bluetooth or proto_coverage' -q(394 passed, 8 subtests) — broader BLE regression sweep for the shared bluetooth.py/commands.py import changesmanual diff review of AGENTS.md and docs/bluetooth_vehicles.md against the two recorded review-fix decisionsmanual check of installedtesla-protocol/protobufversions in the locked venv (1.4.0 / 6.33.6) against the intent's stated committed state✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.