Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashlytics integration akin to Bugsnag #645

Open
kitallis opened this issue Sep 18, 2024 · 3 comments
Open

Crashlytics integration akin to Bugsnag #645

kitallis opened this issue Sep 18, 2024 · 3 comments
Assignees
Labels
big feature A substantial feature that should be broken down into small issues category / integrations gitstart tickets for GitStart to pick up

Comments

@kitallis
Copy link
Member

kitallis commented Sep 18, 2024

Context

This is the current set of health metics data stored by Tramline:

# Table name: release_health_metrics
#  daily_users                :bigint
#  daily_users_with_errors    :bigint
#  errors_count               :bigint
#  new_errors_count           :bigint
#  sessions                   :bigint
#  sessions_in_last_day       :bigint
#  sessions_with_errors       :bigint
#  total_sessions_in_last_day :bigint

We will need to transform the data from Crashlytics into a similar form and store it in Tramline.

Figure out the query required to get this data. Make sure to filter by the correct version code and version name.

Fetch frequency can be lower than Bugsnag (every 30 minutes?).

Once the data is fetched and stored, the rest of the health rule application logic remains the same. So, all that is needed from this issue to fetch, transform and store the release health metrics data.

Crashlytics is special because there's no direct API to get this data. We expect Firebase to be connected to the user's account, and we would make calls to the BQ dataset instead. Link to sample BQ data exported to a spreadsheet.

Requirements

  • Write an API layer and integration layer for Crashlytics
  • Ensure the interfaces adhere to the common functions, see Bugsnag integration

Acceptance Criteria

  • UI change required only in connecting the integration, the rest should work seamlessly.
  • Hook up the APIs and integration layer
  • Unit tests & some API-mocked fixture-driven tests
  • Ensure things work as closely as Bugsnag. Test manually properly.
  • Find an estimate of the costs associated with each query. This will help us tweak polling rate and help communicate the unprecedented costs (if any) to our users.

Additional Notes

Here's a sample BQ query that can be used as a starting point for all the other queries to be written:

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `decoded-theme-355014.firebase_crashlytics.com_tramline_ueno_ANDROID_REALTIME`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;
@kitallis kitallis added big feature A substantial feature that should be broken down into small issues category / integrations labels Sep 18, 2024
@kitallis kitallis added the gitstart tickets for GitStart to pick up label Oct 13, 2024
Copy link

Issue synced into GitStart. Please review, edit and hand it off to GitStart by following this link.

Copy link

This issue has been handed off to GitStart: https://clients.gitstart.com/tramline/11653/tickets/TRAB-645

@kitallis
Copy link
Member Author

kitallis commented Nov 6, 2024

Some additional definitions, referenced from https://bugsnagapiv2.docs.apiary.io/#reference/projects/releases/view-a-release

  • errors_introduced_count: the new errors that have been introduced in this release
  • errors_seen_count: the total errors that have been seen in this release
  • sessions_count_in_last_24h: total number sessions for the release in the last 24h
  • total_sessions_count: total number of sessions for the release
  • unhandled_sessions_count: total number of sessions for the release that have had an exception/error
  • accumulative_daily_users_with_unhandled: the total number of users in the release with errors
  • accumulative_daily_users_seen: the total number of users in the release

@kitallis kitallis moved this to In progress in Public Roadmap Nov 7, 2024
@nid90 nid90 self-assigned this Dec 16, 2024
@kitallis kitallis moved this from In progress to Shipped in Public Roadmap Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big feature A substantial feature that should be broken down into small issues category / integrations gitstart tickets for GitStart to pick up
Projects
Status: Shipped
Development

No branches or pull requests

2 participants