Skip to content

[Repo Assist] fix: prevent double PairingStatusChanged fire in hello-ok handler#109

Draft
github-actions[bot] wants to merge 1 commit intomasterfrom
repo-assist/fix-pairing-double-fire-f823bbb6a0628a53
Draft

[Repo Assist] fix: prevent double PairingStatusChanged fire in hello-ok handler#109
github-actions[bot] wants to merge 1 commit intomasterfrom
repo-assist/fix-pairing-double-fire-f823bbb6a0628a53

Conversation

@github-actions
Copy link
Contributor

🤖 This is an automated draft PR from Repo Assist.

Summary

HandleResponse was firing PairingStatusChanged twice whenever a hello-ok response included auth.deviceToken and the client was previously in pending-approval state:

  1. First fire — from the auth block, when wasWaiting was true: PairingStatus.Paired with message "Pairing approved!"
  2. Second fire — immediately after, from the DeviceToken fallback check (lines ~481–498): it saw the token that was just stored by StoreDeviceToken() and fired PairingStatus.Paired again unconditionally.

This is a logical bug: any UI subscriber to PairingStatusChanged would receive two Paired events in rapid succession, which can cause duplicate toasts, double state transitions, or confusing log noise.

Fix

Introduce a bool gotNewToken guard. When a device token is received in the response:

  • Store it, update _isPendingApproval, and fire exactly one PairingStatusChanged event
  • Skip the DeviceToken fallback check (!gotNewToken guard)

The wasWaiting logic is folded into a single conditional message ("Pairing approved!" vs null), so a token refresh on reconnect (when already paired) also fires exactly one event.

The three existing cases all produce exactly one event:

Scenario gotNewToken Event fired
Unpaired, no token in response false Pending
Unpaired, token in response (newly approved) true Paired + "Pairing approved!"
Already paired, reconnect (no token) false Paired + "Already paired"

Root cause

The original code stored the token in block 1 then unconditionally re-checked _deviceIdentity.DeviceToken in block 2 — always firing the else branch after a successful store.

Test Status

Added two regression tests using reflection to invoke HandleResponse directly:

  • hello-ok WITH auth.deviceToken while pending → exactly one Paired event
  • hello-ok WITHOUT token and no stored token → exactly one Pending event
Passed! — Failed: 0, Passed: 505, Skipped: 18, Total: 523

All 505 tests pass including the 2 new regression tests.

Generated by Repo Assist ·

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@cbb46ab386962aa371045839fc9998ee4e97ca64

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants