[HOLD for payment 2024-08-19] [HOLD for payment 2024-08-09] [$250] Associate crashes with specific logins

[roryabraham]

Problem

When users report that their staging or production app crashed, it can be difficult to find the stacktrace for that crash after-the-fact. This makes it harder to identify and fix real-world crashes, leading to a poorer UX in terms of app quality and the level of support we can provide to users who do experience crashes.

Solution

Upon login, associate the user login with crashlytics user ID. That way, if the app crashes, the crash report will be logged along with the login for the user. Then we'll be able to search for crashes by user in the Crashlytics console, and maybe find out more.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019268795ed9fe7be1
• Upwork Job ID: 1795144470205255680
• Last Price Increase: 2024-05-27
• Automatic offers:
• getusha | Reviewer | 102519677
• ShridharGoel | Contributor | 102519678

Issue Owner

Current Issue Owner: @dylanexpensify

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~019268795ed9fe7be1

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[roryabraham]

FWIW I think the code for this is the easy part - testing is the harder part. Not sure what's needed to test crashlytics locally

[dragnoir]

I can see some ideas here for crashing the app https://stackoverflow.com/questions/11807354/how-to-crash-an-android-app-programmatically

[ShridharGoel]

Proposal

Please re-state the problem that we are trying to solve in this issue.

We need a way to associate crashes with IDs.

What is the root cause of that problem?

New feature.

What changes do you think we should make in order to solve the problem?

We can set the userId in crashlytics as soon as the login is done.

Add the below in Expensify.tsx:

useEffect(() => {
if (isAuthenticated) {
    crashlytics().setUserId(Number(session?.accountID).toString()) // We can also use login by getting personal details via Onyx
}
}, [isAuthenticated, session?.accountID])

Note:

We can also add email info using crashlytics().setAttribute('userEmail', userEmail);.
Also, details like device ID etc. can be added in the same way. If logged out, then instead of login we can pass something else like device ID in setUserId.

For testing, we can use crashlytics().crash(); to mock it, and then an internal engineer can check the logs on Firebase.
We'll also need to enable SEND_CRASH_REPORTS in debug mode.

To test native crashes:

Add a new option in TestToolMenu:

<TestToolRow title="Test crash">
<Button
    small
    text="Test crash"
    onPress={() => {
        crashlytics().crash();
    }}
/>
</TestToolRow>

To test JS crashes:

Option 1:

Just add <View>Test</View> anywhere, like in Expensify.tsx or ReportScreen.tsx.

Option 2:

Add a new item in TestToolMenu:

<TestToolRow title="JS crash">
    <Button
        small
        text="JS crash"
        onPress={() => {
            Check
        }}
    />
</TestToolRow>

Since "Check" doesn't exist, this will lead to an exception.

Update firebase.json to set crashlytics_debug_enabled to true.

Note that local logs will show what data is being sent to Firebase, we can use that to verify the changes. Then, once it is on staging, then someone can check on Firebase (using the troubleshoot option).

Native crash would not work on iOS debug build because we are on an old version. See invertase/react-native-firebase#6226

We can also plan to bump the Firebase version in another task.