Error when creating an account on e2e build

[yevh-berdnyk]

trafficstars

Bug Report

Problem

Sometimes when creating an account we get a popup with error:

Expected behavior

No error

Actual behavior

Please shake your phone to report this error... is shown

Reproduction

1. Create a new account

Additional Information

• Status version: nightly
• Operating System: Android

Logs: logcat_shake_the_phone_error.log

[qfrank]

the version seems old in the screenshot you provided? @yevh-berdnyk

I can't find the usage of "start-using-status" in the cljs file on the latest develop branch. Am I missing something? @Parveshdhull

[Parveshdhull]

Yes, the screenshot is old, but I also encountered this error recently, just two days ago. Status-debug-logs.zip

Note: In my case, I might have installed the wrong build while working on the syncing fallback flow, so the logs may not be very helpful and error might have been expected.

[Parveshdhull]

Ok, as per logs shared by @yevh-berdnyk

07-17 19:12:04.124 24559 24667 E ReactNativeJS: 'An error occured while handling the re-frame event:', '[:visibility-status-updates/visibility-status-option-pressed 1]', '\n', 'Within the', ':visibility-status-updates/visibility-status-option-pressed', 'event handler function.'

I removed this call in https://github.com/status-im/status-mobile/pull/21068, so this issue should be fixed

[Parveshdhull]

@yevh-berdnyk @churik are you still facing this issue?

[Parveshdhull]

I removed this call in https://github.com/status-im/status-mobile/pull/21068, so this issue should be fixed

But in my case, error is

'An error occured while handling the re-frame event:', '[:push-notifications/switch false]', '\n', 'Within the', ':push-notifications/switch', 'event handler function.'

[Parveshdhull]

So most probably, problem is with multiaccounts.update/multiaccount-update. As both functions are using this. So we trying to update an no existing multiaccount, and this is causing the crash.

[Parveshdhull]

Ok, real error in my case

node.login error failed to start node: failed to apply migrations: failed to apply status-go/protocol migrations: failed to migrate: file does not exist

[Parveshdhull]

node.login error failed to start node: failed to apply migrations: failed to apply status-go/protocol migrations: failed to migrate: file does not exist

But as I was working on seed phrase fallback and trying different builds, this probably is expected in my case. So if no one else faces this issue, we can close it?

[yevh-berdnyk]

@yevh-berdnyk @churik are you still facing this issue?

Yes, a lot of. For example, here are the logs from Sep 19 nightly build: requests.log geth.log The pop-up appeared when creating a user

[Parveshdhull]

thank you @yevh-berdnyk for confirming. Do you access to Status.log file

[yevh-berdnyk]

thank you @yevh-berdnyk for confirming. Do you access to Status.log file

Not for now. We gather geth and requests logs by script, if you need it, I can add gathering Status.log as well

[Parveshdhull]

Related UX Issue: We are letting user navigate even if account creation is failed.

While testing syncing fallback flow, I changed AllowEmptyDisplayName to false.

I can see error in geth log, but UI is still keeping on-boarding flow as it is. I am not sure why account creation is failing in above cases, but UI should react with these failures.

https://github.com/user-attachments/assets/6160a74d-fb57-4612-a03e-600c959bc4c0

[yevh-berdnyk]

Hi @Parveshdhull, I've discovered that e2e builds don't contain Status.log, only geth and requests. And that's why I can't extract them in e2e tests. Is it easy/fast to be added?

[Parveshdhull]

Hi @Parveshdhull, I've discovered that e2e builds don't contain Status.log, only geth and requests. And that's why I can't extract them in e2e tests. Is it easy/fast to be added?

Hi @yevh-berdnyk, I’m not sure why Status.log is missing from the e2e builds. I didn’t see any related configuration. @siddarthkay, do you have any idea?

Also, could you please share adb logs(if possible) of the device next time this error happens? That would be great!

[churik]

well, we'll switch off the workaround for bug for now and next time we face it, we'll add full adb, I just didn't think it is helpful

[Parveshdhull]

well, we'll switch off the workaround for bug for now and next time we face it, we'll add full adb, I just didn't think it is helpful

Thanks, @churik! That’s will be awesome. For account creation failures, ADB logs are very important. We are logging the failure message directly in Kotlin: AccountManager.kt

[Parveshdhull]

Oh, I checked your PR, and it seems as the workaround we were continuing the flow after the cancel button. That's interesting.

Does this mean that only an error message is shown, but the account is created and the flow works after cancel button pressed?

If this is the case, then I think the node signal is just a little late, and our arbitrary delay is not sufficient.

By the way, as mentioned above, this workaround of adding an arbitrary delay is quite strange. We should only navigate to the allow notification screen on a success event; that should resolve both this issue and the UX problem.

[churik]

but the account is created and the flow works after cancel button pressed?

Seems yes, but not every time; afterwards there can be some consequences, i.e. use can't connect to peers. But mostly it works.. at least in e2e. And we cannot guarantee that these consequences are related to this particular error.

At the same time users continue to report this particular error almost every day.

For account creation failures, ADB logs are very important.

We're very lucky to get it from the first run, attaching the full logcat

[Parveshdhull]

Thank you very much for sharing the logs.

10-21 12:37:20.569  4827  4957 D AccountManager: restoreAccountAndLogin
10-21 12:37:20.579  4827  4957 D AccountManager: restoreAccountAndLogin success: {"error":""}

The account restoration succeeded, so I believe the e2e issue is primarily related to our delay logic. I will address this. 👍

Seems yes, but not every time; afterwards there can be some consequences, i.e. use can't connect to peers. But mostly it works.. at least in e2e. And we cannot guarantee that these consequences are related to this particular error.

Once this issue is fixed, the scenarios involving other issues will be more visible (and easier to differentiate), allowing us to address them effectively.

[Parveshdhull]

Hi @churik,

Quick question: When a user fresh installs the app from the Play Store and the account creation fails and if user reports error by shaking device, what log-level file will we receive (info, debug, error)? We won't get ADB logs, right?

I’m asking because we don’t log account creation errors in CLJS, only in Kotlin (ADB). I can log them in CLJS using log.Error, but will we have those logs for a fresh install before any settings are updated? (probably not 🤔 ?)

cc @ilmotta

[Parveshdhull]

https://github.com/status-im/status-mobile/issues/20996#issuecomment-2346722063 Ok, so no error logs by default. Still I think we should atleast log errors in CLJS for users who have logging enabled, they will be useful if an error happens when creating more accounts. It could also help with debugging PR builds. wdyt @ilmotta?

[ilmotta]

@churik @Parveshdhull @qfrank:

I can reproduce this problem 100% of the time with the steps below:

1. make release-android BUILD_TYPE=release.
2. Do a fresh install, run adb install result/app-arm64-v8a-release-signed.apk
3. Open app and create a profile. In the Enable notifications screen, pressing on the button Maybe later triggers the pop-up.
4. If I press Cancel in the pop-up and press Maybe later again, eventually I can login.
5. After login the problem never occurs again. The wallet account is never empty in my reproduction steps, so I'm not reproducing https://github.com/status-im/status-mobile/issues/21151https://github.com/user-attachments/assets/7beddf57-c3d6-42e4-8b18-90658fd699ca

In this setup, every single profile creation will trigger the pop-up. If I wait ~10s before pressing Maybe later, the pop-up does not appear. Therefore @Parveshdhull, as you said here https://github.com/status-im/status-mobile/issues/20806#issuecomment-2426634343, there's a timing/ordering bug. The bug is not random if I follow the steps above, the timing is always the same as well, so it's quite deterministic, which is good news.

---

https://github.com/status-im/status-mobile/issues/20996#issuecomment-2346722063 Ok, so no error logs by default. Still I think we should atleast log errors in CLJS for users who have logging enabled, they will be useful if an error happens when creating more accounts. It could also help with debugging PR builds. wdyt @ilmotta?

@Parveshdhull, in a release build the LOG_LEVEL is empty, but geth.log will print WARN and ERROR logs. As far as I checked, when the user creates a profile and changes the log level in the settings, that level is only used for that profile and won't survive after logout. After logout or upon reopening the app the log level will be the default set at build time. Sorry if I misunderstood your question.

[qfrank]

We should only navigate to the allow notification screen on a success event; that should resolve both this issue and the UX problem.

Perhaps allow the notification screen after node.login. This seems reasonable. Replying with a specific delay value (7000) is not ideal. @Parveshdhull