[HOLD for payment 2022-02-02][$8000] - iOS - User stuck on Splash screen when launching the app

[isagoico]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Force close the app or update the app
2. Open the app

Expected Result:

User should not be stuck on Splash screen

Actual Result:

User is stuck in splash screen

Workaround:

Closing and reopening app fixes the issue.

Platform:

Where is this issue occurring?

• iOS

Version Number: 1.1.2-0

Reproducible in staging?: Yes
Reproducible in production?: Unknown

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation
There's no solid reproduction steps but from the testers reproductions it has been after updating the app.

Expensify/Expensify Issue URL:

Issue reported by: @puneetlath
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1632958388281500

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @iwiznia (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[MelvinBot]

Triggered auto assignment to @kadiealexander (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[kadiealexander]

Upwork post: https://www.upwork.com/jobs/~018ca1e70adf6f82c2

[zoontek]

@cmvithanage You mean that the ErrorBoundary trick (wrapping onyx) I recommend first, before trying to implement all of these would have worked? 😨

[kidroca]

it seems that the app is trying to use an expired token to authenticate on resume and the exception thrown isn't handled properly, which is causing the app to get stuck on the splash screen.

Can you point out where the code might be throwing an exception and how it isn't properly handled?
We do handle expired tokens and authentication errors and retry
The comment you refer to says authentication is successful "a little later" (from the retry)

@cmvithanage You mean that the ErrorBoundary trick (wrapping onyx) I recommend first, before trying to implement all of these would have worked? 😨

No
According to @cmvithanage's comment our server rejects a response due to expired token and this results in an error.
How's wrapping Onyx or the whole app tree would help here?
Error Boundary would not catch such errors anyway as they happens in a promise

Besides you pointed out that the logic that used view controller had a flaw where the controller is nil during init - like when you open the app from a push notification. And this results in .hide not working

[zoontek]

@kidroca Yes, reading the log we can see that the Promise is correctly called but never resolve. So that's why I don't understand @cmvithanage comment (Honestly this looks like a state resume issue.)

[kidroca]

@kidroca Yes, reading the log we can see that the Promise is correctly called but never resolve. So that's why I don't understand @cmvithanage comment (Honestly this looks like a state resume issue.)

I think the log is just cut too short (maybe because there's nothing of interest). I think this line indicates the spash should have been hidden:

[alXt] [BootSplash] splash screen is still visible ~~ props: '[preferredLocale: 'en' isSidebarLoaded: '1' initialReportDataLoaded: '1' updateAvailable: '' screenShareRequest: '' isAuthenticated: '1']'

1. No logs from the ErrorBoundary indicate that the app didn't crash
2. isSidebarLoaded: '1' indicates the app didn't crash - the sidebar component loaded
3. isSidebarLoaded, initialReportDataLoaded and isAuthenticated are all true which means the error boundary should have been hidden - the authentication call doesn't matter

[kidroca]

@NikkiWines the log window seem to be too small

• we don't see calls to Bootsplash.hide and the data indicates there should have been such. I think they happened outside of the snipped you posted
• we also don't see whether the Authenticate call succeeds
• we don't see whether there was a prior crash logged by the Error Boundary

The log snipped that you posted happens 30 sec. after app launch. To be certain we have the full picture - we need to see the logs from the start - and logs for maybe 15-30 sec after [alXt] [BootSplash] splash screen is still visible was logged.

[cmvithanage]

Thanks for the explanation, @kidroca. I agree, need to see the full log to get a complete picture of what's exactly causing this issue.

If @NikkiWines or someone else can kindly post the full log while replicating this issue, I'll be happy to take a look during my free time and get back to you all! 🙌🏼

[NikkiWines]

The log snipped that you posted happens 30 sec. after app launch. To be certain we have the full picture - we need to see the logs from the start - and logs for maybe 15-30 sec after [alXt] [BootSplash] splash screen is still visible was logged.

There are no logs associated with my email address for over a minute before the snippet I shared above. That snippet was the particular request associated with the [alXt] [BootSplash] splash screen is still visible was logged. line. You're right, though, that I should've shared a larger set to begin with to provide more context.

Here are the logs from a larger time window: 2022-01-06 23:19:00 UTC to 2022-01-06 23:22:16 UTC. [alXt] [BootSplash] splash screen is still visible occurs at 23:21:14 UTC. Let me know if you need a larger range!

2022-01-06.log

[zoontek]

@NikkiWines IMHO it's good, I though @cmvithanage was working for Expensify and his affirmation was linked to some company internal reproduction / discovery. But if it's not, I invite you to give a try to the latest implementation (without UIViewController) as it has been reviewed already 🙂

[cmvithanage]

@zoontek No, I'm only an interested individual trying to help you guys solve this issue. 🙌🏼

[kidroca]

TLDR

• The requests seems fine.
• The logs are incomplete
• But the splash screen is still visible even though all the conditions to hide it are set to true

---

Incomplete logs

One of the very first things happening during init is [Migrate Onyx] start and we don't see such logs prior to [alXt] [BootSplash] splash screen is still visible
The logs also confirm this - we see a request finishing (successfully), with no prior "[info] Making API request" logs

2022-01-06 23:21:14 194	 PID ~~ 4145313
...
2022-01-06 23:21:14 198	 [info] Finished API request ~~ command: 'Get' ... jsonCode: '200'

Shortly after we see the [alXt] log

2022-01-06 23:21:14 235	 [alXt] [BootSplash] splash screen is still visible

---

The logs that follow reveal that everything is panning out OK and we do call BootSplash.hide()
I'm not certain whether these logs are from the same session, or after @NikkiWines restarted the app
Though if the problem is the view controller it doesn't really matter

We don't see another [BootSplash] splash screen status log, which implies the logs are from the same session
In that case:

• the BootSplash.hide() is getting called after [info] [BootSplash] splash screen status - that's more than 30 sec. after init
• BootSplash.hide() didn't hide the splash screen

---

In the end it seems like everything is tied to the view controller

• We either called hide outside the logs and it didn't work (due to the view controller being nil thing)
• Or we're calling hide after more than 30 sec. but it still didn't work (due to the view controller)

[NikkiWines]

I'm not certain whether these logs are from the same session, or after @NikkiWines restarted the app

I believe in this instance I didn't do anything and just left my phone with the splash screen on it for 3-4 minutes, then restarted the app. But I can wait till this happens again to me and post logs from that instance as well.

[mallenexpensify]

@NikkiWines let me know if I can help with testing too, I don't know how snag logs for this. I'm still experiencing the issue

[zoontek]

@mallenexpensify With the version that embed the module? Then the cause is probably not the module.

[mallenexpensify]

Experiencing issue on production iOS app, v 1.1.30-3 @zoontek

[zoontek]

@mallenexpensify I don't think the production app includes the new module yet (cf this message: #7096 (comment)). But maybe others could confirm 🙂

Edit: it appears to be in staging version, 1.1.31-2

[NikkiWines]

Not to jump to conclusions or anything, but encouraging news.

According to our logs, there have been 80 instances of [alXt] [BootSplash] splash screen is still visible ~~ since Friday, but 0 instances where the app version was 1.1.31-2 or 1.1.32-0 (which is the prod version that was deployed only a couple hours ago)

[mallenexpensify]

I'm see 1.1.31 as the most recent version for iOS, could that be why? it hasn't been deployed to app store yet?

[NikkiWines]

My app version on testflight is 1.1.33.1 so at least some Expensify employees should be on a version that includes @zoontek's most recent changes.

Expensify employees also seem to be the ones most commonly experiencing this bug, probably cause we use the app throughout the day.

[mallenexpensify]

Thanks @NikkiWines , since it appears there are multiple PRs associated with this issue, can you drop in a note stating when to pay?

[NikkiWines]

From this comment in the last PR we can see that @zoontek's changes were deployed to prod yesterday (2022-01-26), so we'd want to issue payment on 2022-02-02 assuming we don't see the splash screen issue resurface between now and then.

So far everything is looking good, checked the logs today and we had 120 instances of [alXt] [BootSplash] splash screen is still visible ~~ (which has been a solid indicator of the bug popping up) since Friday, but still 0 instances where the app version was 1.1.31.2 or above

I'll keep an eye on the logs this week to see if anything pops up - and I'll post in #expensify-open-source tomorrow evening asking if anyone on the staging or prod versions has experienced this. I can say I haven't experienced this myself since the PR was deployed to staging, without any change in behavior on my end.

[NikkiWines]

Posted in slack today to ask if anyone is experiencing this bug.

Logs say 340 instances of this bug past two weeks but again nothing on 1.1.31-2 or above 🎉

[mallenexpensify]

fwiw.. it hasn't happened to me for a few days.
Do you know when payment is due? @NikkiWines? I scrolled up but don't see the normal auto-post that lists the date nor PR link. I'm going to post in #expensify-open-source that this is fixed and encourage users to update the iOS app

[NikkiWines]

I don't know about the auto-posting, but based on our previous rules of "wait a week after deploying to prod and issue payment if there are no regressions" we would issue payment tomorrow as mentioned here.

Looks like no one in slack has experienced this one either. Great job seeing this through @zoontek and thanks for all the work!

[zoontek]

@NikkiWines I'm glad it solves your issue! Also, I never gained money with react-native-bootsplash / localize / permissions development and maintenance (except ~20$ per month with sponsors). It will be a first, thank you! 🙌

[mallenexpensify]

Thanks @NikkiWines , I missed/forgot the previous comment :ohnothing:
Thanks for the fix @zoontek, it looks like payment was issued on December 14, 2021 for $8000, can you confirm you received?

[zoontek]

Thanks @NikkiWines , I missed/forgot the previous comment :ohnothing: Thanks for the fix @zoontek, it looks like payment was issued on December 14, 2021 for $8000, can you confirm you received?

Indeed, I never checked, but it seems paid.

[mallenexpensify]

🎉 whoohooo 🎉
Thanks again for the help @zoontek ! Closing this 🐶 out