Telemetry

[matux]

Description of the change

Behold! Telemetry.

This PR:

• Adds a manual Telemetry gathering API to the Dart and Flutter Rollbar libraries, no extra configuration required, and it is accessible as follows:

Rollbar.drop(Breadcrumb.log('Tapped faultyMethod button'));

Rollbar.drop(
  Breadcrumb.navigation(
    from: 'initialize',
    to: 'runApp',
  ),
);

Rollbar.drop(
  Breadcrumb.widget(
    element: 'batteryLevel',
    extra: const {'action': 'tapped'},
  ),
);

The word Breadcrumb was chosen as it is the term of art used by Rollbar when describing Telemetry: https://docs.rollbar.com/docs/telemetry.

• Example has been expanded to show how to "drop breadcrumbs" for telemetry gathering.

• Fixes the database not being persisted on Android nor iOS by retrieving the appropriate write directory from each platform:

  • https://github.com/rollbar/rollbar-flutter/pull/66/files#diff-5070a5c9a349072568ae839408896c890b46b5a7228dcf3d658be5aae4212b07R72
  • https://github.com/rollbar/rollbar-flutter/pull/66/files#diff-4dc4b977d56b6522f5a852ecb72245850a8e9a0f462ee04d856ebda02696fcf3

• To imbue any object of persistence capabilities, simply add the Persistence<?> mixin to an object, eg:

class Telemetry with Persistence<BreadcrumbRecord> implements Configurable {

class PersistentHttpSender
    with Persistence<PayloadRecord>
    implements Configurable, Sender {

That's all. The object will be given a TableSet based on the given record, using a shared sqlite3 database, and configured by the Config object as stated by Configurable.

• The lifetime of the persisted records (telemetry, payloads we failed to send) can be configured through persistenceLifetime in Config.

• Improved multi-threading to minimize the amount of processing Rollbar does on the main-thread.

• The CoreNotifier has been generalized into a Notifier from which two types of asynchronous notifiers can be used, AsyncNotifier and IsolatedNotifier, the former uses Dart's asynchronous syntax for single-threaded asynchrony, the latter uses Dart's Isolates for true mutlithreaded asynchrony.

  • IsolatedNotifier is the default.
  • AsyncNotifier is used for unit testing, since tests don't work with Isolates. This allows us to fully test the entire library's process flow from the moment we capture an event to the moment we send the occurrence payload to the server.
  • This is configurable through notifier in Config.

• The minimum required version of Dart and Flutter has been bumped to 3.0.0 to support new features and bring a modern API to users.

• The Body was rewritten to better reflect the json structure it represents and that we send to the server. This was also needed for it to hold telemetry.

• Equality of our payload data structures is now performed deeply to ensure true equality between instances.

  • This allows us to fully test the entire process of serialization and deserialization without having to write tests for each data structure.
  • It also provides a definite way to ensure we don't introduce errors to the (de)serialization process given it's non-typesafe nature.

• Removed Infrastructure and streamlined the process flow from catching an error to sending it to the server.

  • This allows us to better separate our internal process from our user-facing Rollbar object
  • It also allows us to make the entire process asynchronous, (multithreaded or not), with a clear division between main-thread and our thread.
    • Thus now, no data wrangling happens in the main-thread any more.

• Old Infrastructure responsibilities were changed accordingly:
  • The responsibility of asynchronous processing is now done from the Notifier, be it AsyncNotifier or IsolatedNotifier.
  • The Notifier is our internal hub, which holds our wrangler, sender and telemetry, and decides who should be called given the event reported by the user-facing Rollbar object.
  • The responsibility of transforming the data via the Transformer and wrangling it to produce a Rollbar-server-friendly payload we can send is now done from the DataWrangler
  • The responsibility of persisting the data in case of http failure is now done by the PersistentHttpSender.

Other changes

• Removed Result since Rollbar successful response is only an UUID, which we can just keep in the Response object that used to contain the Result.
• To avoid having a null value for when we have no Transformer, a NoopTransformer (no-op) has been created and is now the default. This prevents us from having to do null checks in a few parts of the library, including tests.
• Many more tests.
• More code documentation added.
• Wrote more language and stdlib extensions.
• pana was reverted back to its latest version, the CI will fail since pana insists on using the currently published 0.3.0-beta rollbar_common and rollbar_dart to see if the in-development code works , I'll get in touch with pana devs to understand what we're supposed to do here.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Maintenance
• New release

Related issues

Shortcut stories and GitHub issues (delete irrelevant)

• Feature: Telemetry #67
• Data timestamps are not UTC. #62

Checklists

Development

• Lint rules pass locally
• The code changed/added as part of this pull request has been covered with tests
• All tests related to the changed code pass in development

Code review

• This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• "Ready for review" label attached to the PR and reviewers assigned
• Issue from task tracker has a link to this pull request
• Changes have been reviewed by at least one other engineer

[akornich]

Well done!
I left a couple of suggestions to keep in mind during the next big refactoring phase - related to some classes locations/modules.