fix(accounts): reset transient webview status on rehydrate#1536
Conversation
Embedded-app tabs (Slack, Discord, WhatsApp, Telegram, ...) could open straight onto the "<provider> is taking longer than expected" overlay right after reopening the desktop app. One verified root cause is a Redux-persist hydration leak: Account.status is part of the persisted accounts blob, so a `timeout` (or `loading` / `pending` / `open` / `error`) set in the previous session was replayed on boot before any new webview spawn had started, even though every CEF browser is destroyed at shutdown. Treat any non-`closed` status as session-local and reset it to `closed` on REHYDRATE for the `accounts` persist key, matching the existing pattern in notificationSlice. Account directory, order, activeAccountId, lastActiveAccountId, and provider login sessions (owned by CEF user-data-dir, not Redux) are untouched. Adds an `accounts:rehydrate` debug log capturing the reset count + previous statuses so future Sentry/log captures can confirm the hydration path was taken. Covered by a new rehydrate suite that exercises every transient status, multi-account directories, the persisted MRU pointer, and REHYDRATE actions targeted at sibling persist keys. Refs tinyhumansai#1379
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds redux-persist ChangesAccount status rehydration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Embedded-app tabs (Slack, Discord, WhatsApp, Telegram, ...) could open straight onto the " is taking longer than expected." overlay right after reopening the desktop app, even though every CEF browser is destroyed at shutdown so the timeout had no live session left to be about.
One verified root cause is a Redux-persist hydration leak.
accountsPersistConfigwhitelists the fullaccountsblob — includingAccount.status— so a transient status (timeout/loading/pending/open/error) set in the previous session was replayed on the next cold boot before any new webview spawn had started.WebviewHostreadsstatus === 'timeout'straight from Redux, so the retry overlay rendered before frame 1.Treat any non-
closedstatus as session-local and reset it toclosedonREHYDRATEfor theaccountspersist key, matching the existing pattern innotificationSlice. The persisted account directory, ordering,activeAccountId,lastActiveAccountId, and provider login session (owned by the CEF user-data-dir, not Redux) are untouched, so users still land on their accounts list with logins intact.What changed
app/src/store/accountsSlice.ts— newREHYDRATEextraReducerthat flips every account's transient status toclosed, clearslastError, and emits aaccounts:rehydratedebug log with the reset count + previous statuses for future triage.app/src/store/__tests__/accountsSlice.rehydrate.test.ts— 10 vitest cases covering every transient status, theclosed-stays-closedinvariant, multi-account directories, the persisted MRU pointer, andREHYDRATEactions targeted at sibling persist keys.Acceptance criteria — coverage
retryWebviewAccountLoad) is unchanged. If the live load times out the user still gets the retry overlay.accounts:rehydratedebug namespace logs the reset count + previous statuses so future Sentry/log captures can confirm the hydration path was taken.Scope caveat — not closing the issue
This PR addresses one verified root cause that is clearly wrong on its own (transient session state has no business surviving a process restart). I did not reproduce the original Slack screenshot end-to-end — that needs a real Slack OAuth + dirty-close + cold-reopen cycle with a slow network. Other plausible paths to the same overlay are not touched here:
IDLE_BUDGET(8s).Keeping #1379 open until the reporter confirms the repro is gone in a release build; if the overlay still appears, the remaining causes above are the next follow-up. Linking with
Refsinstead ofCloseson purpose.Refs #1379
Summary by CodeRabbit