Android - User is logged out randomly

[isagoico]

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

---

Action Performed:

1. Use the Android app daily and don't log out from the account.

Expected Result:

User should not be logged out randomly.

Actual Result:

User is being logged out randomly.

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Android

Version Number: 1.1.2-0

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

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

Notes/Photos/Videos: Any additional supporting documentation
We haven't found reproducible steps yet. Seem like a random scenario. @quinthar has been able to reproduce twice.

Expensify/Expensify Issue URL:

Issue reported by: @quinthar
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1632379894048100

View all open jobs on GitHub

[MelvinBot]

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

[marcochavezf]

I wasn't able to reproduce this issue yet, but some of the ideas to try are (after reading some of the comments of the Slack thread):

• Force storage eviction, which could be wiping out the authToken.
• Look into the code when/if the authToken is renewed/deleted and then dive deeper into the logs with some insight taken after checking out the code.
• Use a debuggable apk to look into the local logs when the error happens.

[MelvinBot]

@marcochavezf Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[marcochavezf]

Seems an invalid authToken is not part of the issue. I tested out using an invalid authToken with command=Authenticate and the server is responding with a renewed authToken which keeps the user logged in.

The log out happens when the partnerPassword is invalid or the session value (from Local Storage) is deleted (which could be deleted by a bug in react-native-onyx on Android):

[kidroca]

@marcochavezf
Regarding the bug being in Onyx - it's possible but if it's caused by the AsyncStorage library that we use internally there (I don't think it's likely, we can check their issue board for similar reports)
I've traced how Onyx eviction works - it will never even attempt to clear the full storage, it will only remove old chat messages we're not currently accessing

Onyx would never call Onyx.clear to clear storage on its own - only through an external call (from Expensify.App)
The only such call is here:

App/src/libs/actions/SignInRedirect.js

Lines 22 to 27 in 04083b1

	function clearStorageAndRedirect(errorMessage) {
	const activeClients = currentActiveClients;
	const preferredLocale = currentPreferredLocale;
	// Clearing storage discards the authToken. This causes a redirect to the SignIn screen
	Onyx.clear()

This is triggered on regular user log outs or cases like the one you've posted above where partnerPassword is invalid

[kidroca]

A very likely cause I think is credentials not being read from storage fast enough.

See how credentials don't have an initial value here - it will come from storage at some point

App/src/libs/API.js

Lines 11 to 15 in 04083b1

	let credentials;
	Onyx.connect({
	key: ONYXKEYS.CREDENTIALS,
	callback: val => credentials = val,
	});

If we don't have it by the time reauthenticate is called the request will probably fail (in a similar way it fails for invalid partnerPassword here: #5619 (comment)):

App/src/libs/API.js

Lines 267 to 268 in 04083b1

	partnerUserID: credentials.autoGeneratedLogin,
	partnerUserSecret: credentials.autoGeneratedPassword,

On my physical Android device I've seen delays of up to 3 sec. for retrieving a value from storage during app launch

Can you trace server logs to try and confirm this - Authenticate being called with no (or empty) partnerUserID and partnerUserSecret?

---

IMO we need to ensure that credentials are first read from storage and only then start the request.
Exposing Onyx.get would be beneficial for cases like this e.g.

Onxy.get(ONYXKEYS.CREDENTIALS)
    .then(({ autoGeneratedLogin, autoGeneratedPassword }) => Authenticate({
        useExpensifyLogin: false,
        partnerName: CONFIG.EXPENSIFY.PARTNER_NAME,
        partnerPassword: CONFIG.EXPENSIFY.PARTNER_PASSWORD,
        autoGeneratedLogin,
        autoGeneratedPassword,
        authToken,
    }));

cc @marcaaron and @tgolen regarding Onyx.get suggestion

---

There are 3 instances where we write session data to Onyx and could be overwriting something by mistake, I've traced them further and it doesn't seem likely

setSuccessfulSignInData

App/src/libs/actions/Session.js

Lines 37 to 43 in 04083b1

	function setSuccessfulSignInData(data) {
	PushNotification.register(data.accountID);
	Onyx.merge(ONYXKEYS.SESSION, {
	shouldShowComposeInput: true,
	..._.pick(data, 'authToken', 'accountID', 'email', 'encryptedAuthToken'),
	});
	}

signInWithShortLivedToken

App/src/libs/actions/Session.js

Lines 252 to 260 in 04083b1

	function signInWithShortLivedToken(accountID, email, shortLivedToken, encryptedAuthToken) {
	Onyx.merge(ONYXKEYS.ACCOUNT, {...CONST.DEFAULT_ACCOUNT_DATA, loading: true});
	createTemporaryLogin(shortLivedToken, encryptedAuthToken, email).then((response) => {
	Onyx.merge(ONYXKEYS.SESSION, {
	authToken: shortLivedToken,
	accountID,
	email,
	});

reauthenticate

App/src/libs/API.js

Lines 278 to 283 in 04083b1

	// Update authToken in Onyx and in our local variables so that API requests will use the
	// new authToken
	Onyx.merge(ONYXKEYS.SESSION, {
	authToken: response.authToken,
	encryptedAuthToken: response.encryptedAuthToken,
	});

[marcochavezf]

A very likely cause I think is credentials not being read from storage fast enough.

@kidroca you're right about this ^ but with authToken. There's a race condition issue here, I added a setTimeout to 3 secs to get authToken, refreshed the browser and I was logged out:

IMO we need to ensure that credentials are first read from storage and only then start the request.
Exposing Onyx.get would be beneficial for cases like this e.g.

I think we'll need to ensure that both credentials and authToken are retrieved first from local storage.

[isagoico]

Looks like @johnmlee101 Experienced this issue (or a extremely similar one) in iOS

Image.from.iOS.2.MOV