[Repo Assist] fix: prevent double PairingStatusChanged fire in hello-ok handler#109
Draft
github-actions[bot] wants to merge 1 commit intomasterfrom
Draft
Conversation
When hello-ok includes auth.deviceToken, HandleResponse was firing PairingStatusChanged twice: 1. From the auth block when wasWaiting (Paired + 'Pairing approved!') 2. From the DeviceToken fallback check below, which saw the newly-stored token and fired Paired again unconditionally. Fix: introduce a gotNewToken guard so the DeviceToken fallback check is skipped entirely when a token was received in the response body. This ensures exactly one PairingStatusChanged event fires per hello-ok regardless of whether the device was previously pending approval. Add two regression tests using reflection to invoke HandleResponse: - hello-ok WITH deviceToken while pending => exactly one Paired event - hello-ok WITHOUT deviceToken and no stored token => exactly one Pending event Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
26 tasks
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
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.
🤖 This is an automated draft PR from Repo Assist.
Summary
HandleResponsewas firingPairingStatusChangedtwice whenever ahello-okresponse includedauth.deviceTokenand the client was previously in pending-approval state:wasWaitingwastrue:PairingStatus.Pairedwith message"Pairing approved!"DeviceTokenfallback check (lines ~481–498): it saw the token that was just stored byStoreDeviceToken()and firedPairingStatus.Pairedagain unconditionally.This is a logical bug: any UI subscriber to
PairingStatusChangedwould receive twoPairedevents in rapid succession, which can cause duplicate toasts, double state transitions, or confusing log noise.Fix
Introduce a
bool gotNewTokenguard. When a device token is received in the response:_isPendingApproval, and fire exactly onePairingStatusChangedeventDeviceTokenfallback check (!gotNewTokenguard)The
wasWaitinglogic is folded into a single conditional message ("Pairing approved!"vsnull), so a token refresh on reconnect (when already paired) also fires exactly one event.The three existing cases all produce exactly one event:
gotNewTokenfalsePendingtruePaired + "Pairing approved!"falsePaired + "Already paired"Root cause
The original code stored the token in block 1 then unconditionally re-checked
_deviceIdentity.DeviceTokenin block 2 — always firing theelsebranch after a successful store.Test Status
Added two regression tests using reflection to invoke
HandleResponsedirectly:hello-okWITHauth.deviceTokenwhile pending → exactly one Paired eventhello-okWITHOUT token and no stored token → exactly one Pending eventAll 505 tests pass including the 2 new regression tests.