[$250] Chat - Unending skeleton is displayed on first time sign-up

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.4.73-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Navigate to sign-up page
2. Sing-up with a new account
3. Open Self DM

Expected Result:

Concierge and Self DM report should load

Actual Result:

Unending skeleton is displayed on Concierge and Self DM report

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6479178_1715595380688.Screen_Recording_2024-05-13_at_1.09.41_in_the_afternoon.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01bf03f46c9583a214
• Upwork Job ID: 1790013644495663104
• Last Price Increase: 2024-05-13

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open Staging deploy checklist to see the list of PRs included in this release, then work quickly on the following:

1. If you find which PR caused the issue/bug, you can reassign it to the person responsible for it.
   • If the author is OOO or won’t get online before the daily deploy is due, you are responsible for finding the best fix/path forward. Don’t hesitate to ask for help!
2. Try to reproduce the issue, if the bug is on production, remove the DeployBlocker label but stay assigned to fix it (or find out which PR broke it to get help from the author).
   • You can adjust the urgency of the issue to better represent the gravity of the bug.
   • If the issue is super low priority, feel free to un-assign yourself.
   • Be careful with PHP warnings, sometimes it is more complex than just adding a null coalescing operator as they might be uncovering some bigger bug.
   • If it was a one-off issue that requires no action (for example, Bedrock was down or it is a duplicated issue), you can close it.

Remember rule #2: Never un-assign yourself from a real DeployBlocker unless you are 100% sure someone else is assigned and will take care of it.

[melvin-bot]

Triggered auto assignment to @mountiny (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[lanitochka17]

@mountiny FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #vip-vsp

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01bf03f46c9583a214

[melvin-bot]

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

[mountiny]

I could repro in staging

[mountiny]

It seems like no OpenReport call is being made 🤔

[mountiny]

@ishpaul777 Suggested that reverting https://github.com/Expensify/App/pull/41448/files fixes the issue. @ikevin127 are you available to handle the revert so we can CP the fix?

[ikevin127]

Discussing this on C+ Slack 🧵.
Note: So far looks like false alarm -> staging server (BE) issues and not a regression / FE issue.

[mountiny]

I cannot reliably reproduce this one really. Seems like its linked to staging servers being slower now and thats why it shows up as loading for a long time

Hence I dont think this must be a deploy blocker given this behaviour.

I will keep this open to see if there are any hints at App related changes

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[mountiny]

I could still reproduce now and its really weird, I am on limited availability now so I will try to continue investigating when I can but adding the label again

[mountiny]

It works fine in production

[Beamanator]

I'm also noticing this problem, even after logging out / in in staging (on a very new account), OpenReport isn't getting called so I get an infinite skeleton :/ could it be because we're deploying Auth right now??

[Beamanator]

ooh everything loaded now

[Beamanator]

Hmm - here's what i see when i sign out / back in with that account

[danieldoglas]

I think I know what is causing this, let me find the issue

[danieldoglas]

I think this is the cause: #40044

[danieldoglas]

There's a PR to fix it #42095

[ishpaul777]

i dont think so @danieldoglas I am not able to reproduce this on main at all so not sure if this is solved by that PR

Screen.Recording.2024-05-14.at.3.13.48.PM.mov

[ishpaul777]

Not reproducable even on staging branch

Screen.Recording.2024-05-14.at.3.20.06.PM-1.mov

[Skakruk]

I also think it's not related to #40044, since the page is not reloaded and beforeunload event can't be called.

[Beamanator]

Hmm I'm also not able to reproduce this on main main (dev) but I can reproduce this issue in staging on my main expensify account AND on a brand new account... OpenReport seems to never be called once OpenApp finishes - BUT other chats are loading in the LHN, and clicking on them does call OpenReport 🤷 so maybe this isn't a fire but definitely a blocker

[danieldoglas]

Interesting. Testing locally yesterday, I saw several logs with [info] [Pusher] Received updates, but ignoring it since this is not the active client -

Since we check for active client before doing requests, I noticed that my client was not executing any requests because of that. Iy could not be the case for you guys.

[mountiny]

I have been testing locally using staging branch and staging API and while it took a really long time to load, it did for both concierge and selfDM (might be my wifi though)

These seemed to be the logs with API requests that were made since signing in (and then me switching to the selfDM)

[info] Finished API request in 473ms - {"command":"OpenReport","jsonCode":404,"requestID":"883c83568ee963cf-LHR"}
Log.ts:69 [info] Finished API request in 479ms - {"command":"OpenReport","jsonCode":404,"requestID":"883c83594b3f63cf-LHR"}
Log.ts:69 [info] Finished API request in 836ms - {"command":"OpenReport","jsonCode":404,"requestID":"883c835cb8c263cf-LHR"}
Log.ts:69 [info] Finished API request in 754ms - {"command":"BeginSignIn","jsonCode":200,"requestID":"883c9106283163cf-LHR"}
Log.ts:69 [info] Finished API request in 136085ms - {"command":"SigninUser","jsonCode":200,"requestID":"883c926e3ef763cf-LHR"}
Log.ts:69 [info] Finished API request in 30915ms - {"command":"OpenApp","jsonCode":200,"requestID":"883c95c66ed763cf-LHR"}
Log.ts:69 [info] Finished API request in 5725ms - {"command":"OpenApp","jsonCode":200,"requestID":"883c96850ad763cf-LHR"}
Log.ts:69 [info] Finished API request in 24867ms - {"command":"UpdateAutomaticTimezone","jsonCode":200,"requestID":"883c96aa7d2b63cf-LHR"}
Log.ts:69 [info] Finished API request in 18392ms - {"command":"UpdateAutomaticTimezone","jsonCode":200,"requestID":"883c9743fc7863cf-LHR"}
Log.ts:69 [info] Finished API request in 5164ms - {"command":"GetMissingOnyxMessages","jsonCode":200,"requestID":"883c97b72c0063cf-LHR"}
Log.ts:69 [info] Finished API request in 448ms - {"command":"AuthenticatePusher","jsonCode":500,"requestID":"883c97d80b5763cf-LHR"}
Log.ts:69 [info] Finished API request in 477ms - {"command":"AuthenticatePusher","jsonCode":500,"requestID":"883c97d81b6063cf-LHR"}
Log.ts:69 [info] Finished API request in 660ms - {"command":"OpenReport","jsonCode":200,"requestID":"883c97d79abe63cf-LHR"}
Log.ts:69 [info] Finished API request in 873ms - {"command":"OpenReport","jsonCode":200,"requestID":"883c97db8fb863cf-LHR"}
Log.ts:69 [info] Finished API request in 488ms - {"command":"AuthenticatePusher","jsonCode":500,"requestID":"883c9815a83b63cf-LHR"}
Log.ts:69 [info] Finished API request in 42896ms - {"command":"CompleteGuidedSetup","jsonCode":200,"requestID":"883c9812dc6c63cf-LHR"}
Log.ts:69 [info] Finished API request in 16589ms - {"command":"GetMissingOnyxMessages","jsonCode":200,"requestID":"883c991ecd5863cf-LHR"}
Log.ts:69 [info] Finished API request in 428ms - {"command":"OpenReport","jsonCode":200,"requestID":"883c9986788d63cf-LHR"}
Log.ts:69 [info] Finished API request in 1469ms - {"command":"ReadNewestAction","jsonCode":200,"requestID":"883c9988fba863cf-LHR"}
Log.ts:69 [info] Finished API request in 3173ms - {"command":"GetMissingOnyxMessages","jsonCode":200,"requestID":"883c999288b963cf-LHR"}
Log.ts:69 [info] Finished API request in 2874ms - {"command":"GetMissingOnyxMessages","jsonCode":200,"requestID":"883c99a62a3763cf-LHR"}
Log.ts:69 [info] Finished API request in 397ms - {"command":"OpenReport","jsonCode":200,"requestID":"883c99b8eaf463cf-LHR"}
Log.ts:69 [info] Finished API request in 1391ms - {"command":"ReadNewestAction","jsonCode":200,"requestID":"883c99bb3e1863cf-LHR"}
Log.ts:69 [info] Finished API request in 1884ms - {"command":"GetMissingOnyxMessages","jsonCode":200,"requestID":"883c99c41a2f63cf-LHR"}
Log.ts:69 [info] Finished API request in 662ms - {"command":"OpenReport","jsonCode":200,"requestID":"883c9c00cffd63cf-LHR"}
Log.ts:69 [info] Finished API request in 485ms - {"command":"AuthenticatePusher","jsonCode":500,"requestID":"883c9c037bae63cf-LHR"}
Log.ts:69 [info] Finished API request in 469ms - {"command":"OpenReport","jsonCode":200,"requestID":"883c9c052df663cf-LHR"}
Log.ts:69 [info] Finished API request in 421ms - {"command":"AuthenticatePusher","jsonCode":500,"requestID":"883c9c091b9763cf-LHR"}

Seems like the requests took very long to finish leading to this experienece

[jasperhuangg]

We CP'd #42095 which should fix this issue.

[jasperhuangg]

Can't reproduce on web with fresh accounts, and I was previously able to reproduce very consistently using the same method.

[jasperhuangg]

I've tested it a couple times with fresh accounts and I think it's pretty safe to say that the issue has been fixed, closing