fix: correct NavigationSuperchargerRequest wire-format tag (BREAKING) - #32
Merged
Conversation
order was published at tag 1 as int32; live-vehicle and recovered-schema evidence both show tag 1 carries an unrelated value and the trip-order enum is actually at tag 2. Reserves tag 1/"order" and adds remote_nav_trip_order (RemoteNavTripOrder enum) at tag 2, matching the sibling NavigationRequest / NavigationGpsRequest / NavigationGpsDestinationRequest messages.
The new NavigationSuperchargerRequest.RemoteNavTripOrder enum from the tag fix moves the catalog's total enum count from 236 to 237.
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
CarServer.NavigationSuperchargerRequest.orderwas published at tag 1 asint32. Two independent lines of evidence show that's wrong: a recovered-schema cross-check found tag 1 is actually an unrelatedint64value with the trip-order enum at tag 2, and a live send of the as-shipped command (tag 1 encoding) to a real vehicle produced a signed-delivery ack but no navigation-state change at all - the vehicle silently no-ops it.buf breakingallows for an already-published tag:reserved 1; reserved "order";(blocks reuse of both), then a newremote_nav_trip_orderfield (newRemoteNavTripOrderenum:Unknown/Replace/Prepend/Append) at tag 2 - matching the siblingNavigationRequest/NavigationGpsRequest/NavigationGpsDestinationRequestmessages, which already use this exact enum shape for their ownorderfields.orderfield was sending a malformed request the vehicle ignored. Callers must switch toremoteNavTripOrder(TypeScript) /remote_nav_trip_order(Python). Major changeset.fixtures/golden/navigation_supercharger.json) covering all four enum values, plus matching TypeScript/Python round-trip tests, pinning the corrected tag-2 encoding.buf lint,buf breaking(againstmain),scripts/upstream_coverage.py --mode pinned,scripts/check_reply_coverage.py, andscripts/build_catalog.pyare all green; both language test suites pass.AGENTS.mdas the sanctioned fix for a wrong published tag, since a straight in-place renumber is rejected bybuf breaking(tried it -FIELD_NO_DELETErequires reserving the name too, which then collides with reusing that name at the new tag).