Feat/logging diagnostics upgrade

[thetwai-dev]

Todo:

-Test the changes are working as intended on actual crashnlytics.
-Addresses the open questions.

---

Thank you for opening a Pull Request!

Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open a GitHub issue as a bug/feature request before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests are added/updated (if necessary)
• Ensure the linter passes (./codeAnalysis to automatically apply formatting/linting)
• Appropriate docs were updated (if necessary)

📸 Proof of change (REQUIRED)

Every PR must include a screen recording / video showing the change working.
UI changes must also include before/after screenshots.
Just drag-and-drop the files into the boxes below — GitHub will upload them.
PRs without the required media will be flagged automatically and cannot be merged.

🎥 Screen recording / video (always required)

2026-06-30.22-50-48.mp4

• This change has no user-visible / UI effect (refactor, docs, CI, etc.), so screenshots are not applicable.
  • A maintainer may also apply the non-ui label. A video is still required even for non-UI changes.

Addresses #1291

[cynthiabondi]

@thetwai-dev

Great work getting this PR up! The logging diagnostics upgrade is a solid improvement to our crash tracking. I want to make sure we cross the finish line on this, so here's what I need from you to move it into review:

1. Add a Demo Video: Our process requires a screen recording of changes in action, even for backend work. This helps the review team understand the impact. Can you record a quick demo showing:

   • The new crash key logging in action
   • How it appears in Crashlytics
   • Any improvements to diagnostic visibility

2. Master branch:

   • Rebase your branch against the latest master

[thetwai-dev]

@Elforama I forced crash a few times and they should get sent to Crashnlytics. So feel free to check them out when you are free.

I can't see that side but I imagine it should include these.

1. The new custom keys should be surrounding the error such as capture_session_uuid or last_sync_timestamp.
2. If it was built in release, the stack traces should be visible despite minifying the code. (addresses problem 2 of original issue)

[thetwai-dev]

Addressing the open-ended questions from original issue thread.

1. Currently it's not banned but it makes sense to ban com.google.firebase.crashlytics outside analytics/ since there isn't any other reason why other files should be able to send logs to crashlytics, and can also enforce using Timber as only entry. (However, one exception rule could be in di/AppModule to inject).

2. Unsure.

3. My current pr implementation just stored a list of trees id being imported. This might have been not a good approach since it doesn't tell which tree upload went wrong. Rather it should store the state instead like pending=N;oldest=X;last_error=Y;last_success=Z.
   A single key makes sense to me personally since they're all small info that can combined as a snapshot.

4. Unsure.

5. Come back later.

[thetwai-dev]

This new commit addresses open question 3 from previous message for snapshot of uploading queue. Upon re-inspection, storing the id of trees is not useful since it is only local. So I fixed it to store how many uploading, time and uploadBundleId if it is relevant. It's not the same as this format: pending=N;oldest=X;last_error=Y;last_success=Z. because uploading is done by bundle but I think this new change should show some relevant info now.