OpenApp fires twice on supportal login: no in-flight deduplication for OpenApp

[mountiny]

Version Number: 9.4.50-0
Reproducible in staging?: Needs verification
Reproducible in production?: Yes (observed on production)
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): vit@expensify.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @mountiny
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Sign in to New Expensify on web as an Expensify employee.
2. Start a supportal session into another account from Expensify Classic.
3. Watch the network tab (or backend request logs) while New Expensify finishes loading.

Expected Result:

Exactly one OpenApp request is sent for the newly opened session.

Actual Result:

Two OpenApp requests are sent back to back for the same session. Both run the full app-load payload, so the account pays the OpenApp cost twice.

Analysis

OpenApp has no in-flight deduplication, so two openApp() triggers inside the request window both reach the server.

openApp() sends the request through API.writeWithNoDuplicatesConflictAction, which resolves conflicts with resolveDuplicationConflictAction(persistedRequests, matcher):

https://github.com/Expensify/App/blob/main/src/libs/actions/RequestConflictUtils.ts#L60

That resolver only searches persistedRequests. processNextRequest() moves the request that is currently in flight out of persistedRequests and into ongoingRequest:

https://github.com/Expensify/App/blob/main/src/libs/actions/PersistedRequests.ts#L406

So while OpenApp #1 is in flight, the matcher finds nothing, the resolver returns push instead of replace, and OpenApp #2 is enqueued and sent.

ReconnectApp already closes this gap. writeWithNoDuplicatesReconnectConflictAction passes getOngoingRequest() into its resolver, so a ReconnectApp that arrives mid-flight is collapsed:

https://github.com/Expensify/App/blob/main/src/libs/API/index.ts#L71

OpenApp never got the equivalent treatment.

Is this supportal only?

No. The missing in-flight guard is generic — any account that produces two openApp() triggers close together sends two OpenApp requests. Supportal just raises the odds, because the flow signs the agent out, clears Onyx, signs in with the support auth token, and swaps the Public navigator for the Auth navigator. The openApp() trigger in AuthScreensInitHandler runs in a mount-only effect ([] deps), so every remount of AuthScreens fires another one:

https://github.com/Expensify/App/blob/main/src/libs/Navigation/AppNavigator/AuthScreensInitHandler.tsx#L177

The remount during a support login is already documented in signInWithSupportAuthToken, which added a token guard for the same reason:

https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts#L244

Other openApp() callers can stack the same way — PriorityModeHandler, SignInModal, useIsLoadingAppRecovery, and the delegate paths in Delegate.ts.

Prior art

Fix doubled OpenApp on delegate (copilot) account switch was the same class of bug for copilot. It was fixed by removing the two specific triggers, not by adding deduplication, so the underlying gap stayed open.

App hangs when OpenApp / ReconnectApp / GetMissingOnyxMessages fire in rapid stampedes tracks the broader stampede symptom.

Proposed fix

Give OpenApp the same in-flight awareness ReconnectApp has: feed getOngoingRequest() into the conflict resolver so a second OpenApp is dropped or collapsed while one is already running. Fixing it at the dedupe layer covers every trigger at once, instead of chasing each caller.

Workaround:

Yes, users can keep using Expensify. The duplicate request is invisible in the UI beyond a slower app load, and it is more noticeable on large accounts.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @daledah

[mountiny]

a26feebd7f2f29a7-ZRH were the two requests I saw a26fef1b794629a7-SJC

[mountiny]

Production log evidence: this is not supportal only

I checked VictoriaLogs to confirm the "Is this supportal only?" section above. It is not. Regular accounts on all three platforms send the duplicate OpenApp, and the rate is high.

Measurement

Production only, staging excluded. Window 2026-08-06 17:30:00Z to 17:40:00Z.

{type=web} "Processing 'OpenApp' for" NOT host:~"^staging"
| stats count() as total, count_uniq(email) as uniqueEmails

• 459 OpenApp requests
• 351 unique accounts

I then pulled every request in that window with _time, account, policyIDList and clientUpdateID, sorted per account, and measured the gap between consecutive OpenApp calls from the same account:

Gap to previous OpenApp (same account)	Requests
< 2s	60
2–5s	9
5–30s	16
> 30s	23

69 of 459 requests (15.0% of all OpenApp traffic) arrived within 5 seconds of the same account's previous OpenApp. 58 accounts (16.5% of accounts active in the window) had at least one such repeat. Sub-second gaps down to 0.19s were common.

A gap under 5 seconds cannot be a second app open by the user. OpenApp itself takes 5–7s server side on a mid-size account, so the second request is fired while the first is still in flight — exactly the push instead of replace path described above.

Platform split

Platform of the first request in each < 5s pair:

• web: 43
• iOS: 15
• Android: 11

Roughly proportional to traffic. No platform is spared.

Request fingerprint

The pair has a consistent signature that makes it easy to spot in logs. policyIDList on the two consecutive calls:

• empty → populated: 33
• empty → empty: 30
• populated → populated: 6

The first call carries policyIDList: '' because Onyx has just been cleared or hydrated. The second call carries the real policy IDs because call #1's response has already landed.

There is a second, cleaner marker: the first request has no pusherSocketID parameter at all, the second one does. makeRequest.ts reads Pusher.getPusherSocketID(), which is undefined until Pusher connects. So call #1 is fired before Pusher init completes and call #2 after it. Shape of a pair from a regular web account, 0.80s apart:

T+0.00s   policyIDList: ''                              (no pusherSocketID)   clientUpdateID: -1
T+0.80s   policyIDList: '<2 IDs>'  pusherSocketID: '<id>'                     clientUpdateID: '<real ID>'

Same IP, same HTTP_CF_JA4 fingerprint on both, so this is one client, not two tabs.

The supportal session that opened this issue

Client-side openApp() was called 5 times, and 4 of them reached the server as full OpenApp requests. Two of the client calls were only 193ms apart.

Server side (staging), the two requests named in the report plus two earlier ones:

17:58:04.381  policyIDList: ''
17:58:20.263  policyIDList: '<16 IDs>'
17:58:56.977  policyIDList: ''         a26feebd7f2f29a7-ZRH
17:59:12.005  policyIDList: '<2 IDs>'  a26fef1b794629a7-SJC

Each of the last two returned a 14.8MB Auth payload and took 6.3s and 7.5s respectively, ~88% of it inside Auth. So the doubled cost is real, not just an extra round trip.

The client logs show what triggers the refire at 17:58:56:

17:58:56.105  [Pusher] Attempting to disconnect from Pusher before initialization has occurred, ignoring.
17:58:56.242  [Network] API request error: Request canceled — The user aborted a request.
              request: command: 'OpenApp' policyIDList: '[]' canCancel: '1'
17:58:56.550  [App] isLoadingReportData set to true — command: 'OpenApp'
17:58:56.743  [App] isLoadingReportData set to true — command: 'OpenApp'

An in-flight OpenApp is aborted by the session teardown, then openApp() fires twice more 193ms apart. Between those two calls the queue logged:

17:58:56.685  [SequentialQueue] Checking if client is leader — persistedRequestsLength: '1' hasOngoingRequest: ''

so the first of the pair was already queued when the second arrived, and both still went out. The 15s wall-clock gap between the two server requests is the sequential queue holding request #2 until #1 finished, not a 15s pause in the client.

Bottom line

The supportal flow makes it near certain by clearing Onyx and remounting AuthScreens, but the missing in-flight guard fires for ordinary logins too, at roughly 15% of all OpenApp traffic. Fixing it at the dedupe layer as proposed covers both.

Reproducing

{type=web} "Processing 'OpenApp' for" NOT host:~"^staging"
| stats by (email) count() as openAppCount
| filter openAppCount:>1
| sort by (openAppCount desc)

{type=web} "Processing 'OpenApp' for" NOT host:~"^staging"
| extract "policyIDList: '<policyIDs>'"
| extract "clientUpdateID: '<cuid>'"
| extract "platform: '<platform>'"
| fields _time, email, request_id, policyIDs, cuid, platform

[BartekObudzinski]

I didn't know about this issue but I found simillar case on Sentry when I was investigating Inbox. It looks like simillar case to this one I have already prepared changes just I need to test it