fix(settings): stop re-arming WeChat QR poll interval on every refresh - #206
Merged
Conversation
PR-FE-BUG-HUNT-2 (MEDIUM from kenji-led bug-hunt 2026-06-24 round 1): `WechatQrLoginModal`'s 3-second polling effect listed the whole `result` object in its dep array. Every successful QR refresh produces a new `result` reference → effect cleanup tears down the interval → effect re-armed → 3-second clock restarts from zero. In practice the polling cadence drifted: each refresh pushes the next poll up to ~5.9 s after the previous poll instead of the intended 3 s. Over a long scan, this delays the moment the modal notices `loggedIn: true` from the bridge. Fix: derive a boolean `shouldPollQr = !!result?.ok && !result.loggedIn && !result.expired` and depend on `[shouldPollQr]`. The interval is armed once when scanning starts and torn down once when the gating state flips (logged in, expired, or error). `reloadQrCode` only touches stable refs (`loadingQrRef.current`) and state setters, so the captured closure is safe across renders. Scoped to a single function (`WechatQrLoginModal` at lines 687-693) to keep merge surface minimal with the in-flight PRs #202 / #204.
jackwener
added a commit
that referenced
this pull request
Jun 24, 2026
PR-FE-BUG-HUNT-4 (LOW from kenji-led bug-hunt 2026-06-24 round 1): `refreshMessagesUntilTurn` polls `readMessages` every 40ms for up to 1200ms while waiting for a freshly-sent user turn to land in the session journal. The setState was already gated on `activeIdRef.current === sessionId`, but the IPC call itself kept firing until the deadline — burning bandwidth and CPU on a session the user no longer cared about. Fix: check `activeIdRef.current !== sessionId` at the top of each loop iteration AND immediately after the await. Bail early so the polling cycle stops, not just the setState. Same guard on the deadline-fallthrough `refreshMessages(sessionId)`. Behavior change is invisible when the user stays on the same session (common case). Saves up to 30 IPC roundtrips per session-switch during the post-send window when the user navigates fast. Single function, single file. No conflict with #202 / #204 / #206 / #207 since none of those touch `refreshMessagesUntilTurn`.
jackwener
added a commit
that referenced
this pull request
Jun 24, 2026
Kenji aesthetic audit reminder 4/6 (msg `6cc0e04d` 2026-06-24, finding #2): Tooltip is a high-frequency hover/focus surface and should use instant positioning + compositor-only popup transitions. Two sites violated: 1. Positioner: `transition-[top,left,right,bottom,transform]` — `top` / `left` / `right` / `bottom` are layout-trigger properties. Every reposition (e.g. anchor moved by scroll, or side flipped on collision) ran through layout + paint instead of GPU compositor. Reduced to `transition-transform` so the transform-based reposition still tweens smoothly; the layout positioning happens instantly off-frame. 2. Popup: `transition-[width,height,scale,opacity]` — `width` / `height` are layout-trigger. Reduced to `transition-[scale,opacity]`, which is what the data-starting-style / data-ending-style scale-98 + opacity-0 actually animate. The popup-width / popup-height CSS vars still set the size; just no longer transitioned. Net behavior: tooltip pops in/out via scale+fade (compositor), repositions via transform (compositor). Layout properties are applied instantly per frame instead of crossfading. Drawer's `transition-[transform,box-shadow,height,background-color]` and Tabs' `transition-[width,translate]` indicator are flagged in kenji's audit but deferred — both interact with swipe gesture / tab sizing logic and need a focused PR with visual smoke verification. Scoped to 2 lines in 1 file to keep merge surface minimal with the in-flight PRs #202 / #204 / #206.
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.
PR-FE-BUG-HUNT-2 (MEDIUM from kenji-led bug-hunt 2026-06-24).
Bug
`WechatQrLoginModal`'s 3-second polling effect listed the whole `result` object in its dep array:
```tsx
useEffect(() => {
if (!result?.ok || result.loggedIn || result.expired) return undefined;
const interval = window.setInterval(() => { reloadQrCode(); }, 3_000);
return () => window.clearInterval(interval);
}, [result]);
```
Every successful QR refresh produces a new `result` reference → effect cleanup tears down the interval → effect re-arms → the 3-second clock restarts from zero.
The polling cadence drifts: each refresh pushes the next poll up to ~5.9 s after the previous poll instead of the intended 3 s. Over a long scan, the modal notices `loggedIn: true` from the bridge later than it should.
Fix
Derive a boolean `shouldPollQr = !!result?.ok && !result.loggedIn && !result.expired` and depend on `[shouldPollQr]`. Interval armed once when scanning starts, torn down once when the gating state flips (logged in / expired / error). `reloadQrCode` only touches stable refs + state setters, so the captured closure is safe.
Diff
`1 file changed, 11 insertions(+), 2 deletions(-)` — single function, lines 687-693. No conflict with #202 / #204.
Verification
Local disk still ~100% so I couldn't run `pnpm install && pnpm test` end-to-end. Static change, mechanical pattern. Please review the diff + run the suite before merging.