w36-Settings- Refresh page button is unresponsive

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.72-2
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/72388031/folder/52723991/132279183/1726842303?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10
App Component: User Settings

Action Performed:

1. Open the browser Developer Tools console
2. Execute the command Onyx.set('updateRequired', true) to simulate an application update requirement
3. Click the Refresh page button
4. Verify the page reloads and the application boots normally
   Result: the Refresh page button is unresponsive when clicked, and the page does not reload.

Expected Result:

The page should reload successfully, and the application should boot normally.

Actual Result:

Fail last step. The Refresh page button is unresponsive when clicked, and the page does not reload.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7251503_1788552565348.bandicam_2026-09-04_14-59-16-762.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7251503

Issue Owner

Current Issue Owner: @bernhardoj

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/6269ba5f2673c08aaaa35a179d948c70b8efaee24a292db5ad589d4febd2b63f

[MelvinBot]

Proposal

What is the root cause of that problem?

The Refresh page button never reloads because the reload is gated behind a promise that has no .catch() and no .finally().

src/libs/actions/AppUpdate/updateApp/index.ts:9:

clearWorkboxRecoveryCaches().then(() => window.location.reload());

window.location.reload() runs only if clearWorkboxRecoveryCaches() fulfills. If it rejects or never settles, the button is a silent no-op — no reload, no error, no feedback. That is exactly the reported symptom.

This is a regression from #95438 (merged 2026-07-07, labelled [No QA]), which changed that line from an unconditional window.location.reload().

The comparison that pins it: the other error-page refresh button renders the same ButtonComposed in the same ErrorBoundary tree and works, because usePageRefresh calls window.location.reload() directly for everything except chunk-load errors. The cache-clearing gate is the only difference between "refresh works" and "refresh does nothing".

Why the promise can fail to settle on staging/production: clearWorkboxRecoveryCaches deletes every Cache Storage entry and only afterwards unregisters the service workers. The workbox service worker is registered on staging too — CONFIG.ts:102 defines IS_IN_PRODUCTION as process.env.NODE_ENV === 'production', which is true for staging builds (platformSetup/index.ts:77-86). So a click wipes the precache that the still-controlling service worker needs, before that worker is unregistered.

What changes do you think we should make in order to solve the problem?

Make cache clearing best-effort so it can never block the reload:

1. In updateApp/index.ts, replace .then(...) with a .catch() that logs plus a .finally(() => window.location.reload()), so the reload happens on every outcome.
2. Race clearWorkboxRecoveryCaches() against a short timeout (~2s) so a hung Cache Storage or getRegistrations() call cannot strand the user on a dead button.
3. Apply the same shape to usePageRefresh/index.ts:29, which has the identical unguarded .then(reload).

Steps 1 and 2 alone restore the button in every case, including ones we have not reproduced.

What alternative solutions did you explore? (Optional)

• Revert [Payment due @situchan] [No QA] Clear SW caches on web Update Required reload #95438 back to the plain window.location.reload(). That fixes the button but reintroduces the stale-bundle problem that PR was solving.
• Reorder the cleanup to unregister the service worker before deleting caches. Reasonable hardening, but it does not remove the unguarded-promise gate, so it is not sufficient on its own.

Investigation details — hypotheses ruled out, and confidence

Ruled out — the click is blocked by an overlay. Expensify.tsx:293-295 throws CONST.ERROR.UPDATE_REQUIRED, and BaseErrorBoundary.tsx:27-28 calls BootSplash.hide() on the line before it sets the error content — so the splash is always gone by the time the view renders, and the splash is an opaque green full-viewport element anyway (web/index.html:130-145), which the tester would have seen. No other full-screen element survives the throw.

Ruled out — ButtonComposed drops onPress. Traced Button.tsx:170-186 → PressableWithFeedback → BaseGenericPressable.tsx:204; onPress reaches the handler, isDisabled/isLoading default to false, pointerEventsNone is applied only to the label Text, and the same component powers the working GenericErrorPage refresh button.

Ruled out — the state survives the reload. updateRequired is ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED (ONYXKEYS.ts:604) and is registered in ramOnlyKeys at src/setup/index.ts:77. Onyx never persists or rehydrates those, so a real reload always clears it.

Ruled out — Platform.OS !== 'web' short-circuit. react-native is aliased to react-native-web in the web build, so Platform.OS === 'web'. And even if it returned early, the function is async, so .then(reload) would still fire. That guard can never suppress the reload.

Adjacent bug worth a separate issue: UpdateAppModal.tsx:22-32 wires the "update available" confirm button to handleClose, so it just dismisses the modal and never calls updateApp. That leaves UpdateRequiredView as the only caller of updateApp anywhere in the app.

Confidence: medium-high. The defect is a code fact and the regression is pinned to a specific PR. Which failure mode fires at runtime (a hang versus a rejection) is not confirmed — an automated web repro was attempted but the repro needs DevTools console execution, which the browser automation cannot do. To confirm on staging, open DevTools, run the repro, click the button, and check whether [SW] Failed to clear Cache Storage during app reset or an unhandled promise rejection appears. The recommended fix is correct either way.

Related issues: a scan of open Expensify/App issues for this symptom found no duplicate.

💡 Suggested AI code review rule

This looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-19 — Never gate a required side effect on a best-effort promise
• Condition: Flag when a critical, user-visible action (window.location.reload(), sign-out, navigation, closing a modal) is invoked only inside .then() of a cleanup or telemetry promise with no .catch() and no .finally(). Move the action into .finally(), and time-box the cleanup.
• Why: If the best-effort promise hangs or rejects, the action never runs and the UI becomes a silent no-op with no error surfaced. This is the mechanism behind w36-Settings- Refresh page button is unresponsive #100437.
• Search pattern: \.then\(\s*\(\)\s*=>\s*(window\.location\.reload|Navigation\.|Session\.signOut) where the same statement contains neither .catch( nor .finally(
• Offending code (❌): updateApp/index.ts:9 and usePageRefresh/index.ts:29
• Overlap note: CONSISTENCY-6 (Ensure proper error handling) is adjacent but covers unreported errors, not the primary action never running. Amending CONSISTENCY-6 instead of adding a new rule is a reasonable call.

The full rule file, with the ❌/✅ code inline in App's coding-standards format, would live in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100437) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · no recording available

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[bernhardoj]

@MelvinBot I'm able to repro it on staging, but never on dev. Do you know why?

Also, there is no error. It's just clearWorkboxRecoveryCaches taking longer to resolve after being used more than once.

[MelvinBot]

Dev never has a service worker, so there is nothing for clearWorkboxRecoveryCaches to wait on. On staging there is one, and the two awaits in that function get queued behind Workbox's precache install — which restarts from zero on every refresh because the previous click just deleted the precache. Hence: no error, just an ever-growing wait.

Why dev is immune

GenerateSW is only added to the build for non-dev env files (config/rsbuild/rsbuild.common.ts:494-497), and registration is gated on Config.IS_IN_PRODUCTION (platformSetup/index.ts:77-86). Staging builds set NODE_ENV=production, so staging gets the worker; dev gets neither the file nor the registration.

So on dev, clearWorkboxRecoveryCaches hits caches.keys() → only the tiny CacheAPI entries, and getRegistrations() → []. Both resolve in single-digit ms and the reload always fires.

Why it degrades on staging with repeated use

The precache is deliberately huge — vendor ~6.5 MiB, main ~5.5 MiB, authScreens.prefetch ~6.3 MiB, canvaskit.wasm ~7.6 MiB, all precached with maximumFileSizeToCacheInBytes: 10 MiB. The loop is:

1. Click → delete workbox-precache-v2-* → unregister → reload.
2. On boot, platformSetup registers /service-worker.js again. With skipWaiting: true + clientsClaim: true it activates and claims the page immediately, while cache.addAll() is still writing ~25 MB back from the network.
3. Click again → both awaits now serialize behind that install:
   • caches.delete(name) queues behind every in-flight put on that cache.
   • registration.unregister() queues behind the in-progress install job for the same scope (the SW job queue is per-scope FIFO).

Each click wipes the precache, so step 2 is a full cold re-fetch every time — and clicking again before it settles lengthens the queue rather than resetting it. Nothing rejects, so nothing logs.

What this changes about the fix

The .catch() half of my earlier proposal is not the point — a timeout is. Concretely, in updateApp/index.ts:9 and usePageRefresh/index.ts:29:

• Promise.race([clearWorkboxRecoveryCaches(), timeout(~1500ms)]).finally(() => window.location.reload()) — the reload must never be gated on cleanup finishing.
• Inside clearWorkboxRecoveryCaches, unregister before deleting caches. Unregistering is the part that actually breaks the stale-shell loop; deleting the precache first is what creates the re-download that makes the next call slow. Workbox already prunes outdated precache entries on install, so the blanket caches.delete is mostly redundant here.

Confirming which await is the slow one

I could not instrument this directly — the mechanism is derived from the build config and the SW/CacheStorage queueing model, not from a staging trace. If you want to pin it, run this on staging before clicking Refresh the second time:

console.time('keys'); await caches.keys(); console.timeEnd('keys');
console.time('del');  await Promise.all((await caches.keys()).map(n => caches.delete(n))); console.timeEnd('del');
console.time('unreg'); const r = await navigator.serviceWorker.getRegistrations(); await Promise.all(r.map(x => x.unregister())); console.timeEnd('unreg');

If del dominates it's CacheStorage contention; if unreg dominates it's the SW job queue. The fix above covers both.

---

view run · view recording