❗ Login on fresh install resulting in dashboard error and "not logged in" #1002
Comments
|
@Abby-Wheelis is this reproducible? If you log out and log in again, does the same thing happen? |
|
It’s reproducible on first login after install, but fine on second login
after install
…On Thu, Oct 5, 2023 at 1:57 PM shankari ***@***.***> wrote:
@Abby-Wheelis <https://github.com/Abby-Wheelis> is this reproducible? If
you log out and log in again, does the same thing happen?
—
Reply to this email directly, view it on GitHub
<#1002 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANCO3F2BZO6IKJCJ2KY72RTX54GMJAVCNFSM6AAAAAA5UP4DMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBZGU2TSOBXGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
if somebody can fix it by tonight, I can include it with e-mission/e-mission-phone#1050 |
|
I have been unable to reproduce it in the devapp, even on a 'production' bundle. |
|
we should look at logs from the test phones (Profile -> Email Log, instructions for looking beta test debugging are in the README). If the logs aren't enough to figure out what is wrong, we should add more logs to this release 😄 |
|
I have downloaded the logs, but haven't been able to interpret them at the command line yet. I'll upload them here once I can get them into a readable format with the instructions |
|
It would be easier if we could just inspect staging releases. Is there a particular reason we don't make them inspectable? |
|
No. I just use the default build settings for cordova. What do I need to do to make them inspectable? |
The whole log is uploaded in Teams, and I pulled the coordinates out to include it here |
|
I can see the leaving and returning as I'm fixing the permissions, and the error that was generated Also, is there a chance that this is related to some of the login-flow issues from Launching app with #1032 pops up permission screen in summary? I could see where leaving and coming back or seeing the permissions earlier than expected could create off behavior with regards to logging in properly. When I log in the second time, the permissions are already handled. |
To try and test this, I just tried logging out, breaking a permission, and logging back in. This had no problems. It's only the fresh install of the app that I've been able to re-create the issue. |
This is an error from the native code ( So on first install, the token is |
That makes sense since the two biggest problems I noticed were the error on the label screen and the "not logged in" message in Profile where I'd expect to see the token.
I was just able to reproduce again, and confirmed that killing the app and reopening it did not fix the issue. One of the times I reinstalled just now, I did not get the error, and noted another difference between that an the installs with the error. On the bad installs, I am asked to take the survey again, but on the successful install login it had a stored response for me. It's still at least 75% bad logins on first install for this phone. It seems like the lack of survey found probably has to do with the null token, but maybe it can help further diagnose the issue. |
|
I'm glad that we have a phone where it is 75% reproducible - it would be worse if it were only 1% reproducible on a customer phone 😄 Given that it is not 100% even on this phone, my assumption is that it is some kind of race condition with storing the data in the auth plugin so that it can be read by the native code. I don't think it is affected by e-mission/e-mission-phone#1050 but I will push that out to staging anyway so we can confirm. In the interim, it would be good if we could also include some additional logs around the code that saves the auth and get them into tonight's release. That way, the logs we get tomorrow will hopefully be more helpful. I would suggest adding logs before saving the auth, in the callback after saving, and when trying to read the survey. Make sure to use @JGreenlee @Abby-Wheelis LMK if one of you can do this, otherwise I will see if I can make the changes before creating the release. |
|
@shankari I started the draft PR above, with some more log statements around storing and retrieving the config. There is already a log statement with after the response is stored, for my failed login that read If anyone sees any places we should add logs feel free to let me know or add them to my branch (if you don't have write access I'd be happy to enable that) |
|
the token is stored in the config initially. However, it is (or should be) stored into the auth in the equivalent of here: that is the location that the native code reads I'm fixing a showstopper in the admin dashboard, but will take a look after that |
|
The "equivalent" is in I would add some logs there and to |
|
Looking at adding those log statements, I think the issue may be that the user is never getting logged in - the login should be called by this But when I search the log outputs I got, I have several instances of "permission not done, waiting" but none of "permission done, going to log in" If they're not logged in, I'm not sure how the app continues to advance, so I've added another log statement in onboarding state, to see what's happening there and if that can provide any insight. |
in the logs for the bug runs: e-mission/e-mission-docs#1002 I'm not seeing log statements indicating that the user is logged in (which I should see) and so I'm wondering how the onboarding state is moving on in that case. Adding this log statement to investigate.
|
Still reproducible on 1.5.3 for me. Will investigate tomorrow. |
I think this is spot on. I don't see I actually was able to reproduce the issue on my second time through the onboarding process by breaking the location permission, logging out, and trying to log back in. |
|
After some trial and error, I can reproduce this in the devapp on a real phone and can do some more hands-on debugging |
|
The issue results from using our custom hook, When a permission is fixed via So when The path forward seems to be:
|
Now that we have an App component, we can think about hoisting state higher in the component tree so it can be shared instead of being redundant. Rather than hooking into usePermissionStatus from multiple different components, it will be cleaner to hook into it once in the App component and share it downstream via the AppContext. When there were multiple instances of usePermissionStatus, we ran into issues where only one was recieving updates (e-mission/e-mission-docs#1002) Hoisting the permission state to the App component resolves these issues because now there is only one instance of usePermissionStatus
|
Fix is up at e-mission/e-mission-phone#1059. I hope this is the last one! |
|
I just logged in and out on a test phone 6-8 times in a row and did not experience this error any of those times! |
When I uninstalled and reinstalled on my testing iPhone and Samsung devices, I witnessed similar "not logged in" behavior. In both cases, I scanned the opcode and followed the onboarding, but when I landed on the dashboard I saw an error, and when I navigated to the profile page it said "not logged in" where my opcode should display in the first row. In both cases logging out and logging back in restored the app to normal functionality. Screenshots below:
The text was updated successfully, but these errors were encountered: