New event added for sending analytics within package on errors

[eliasyishak]

Fixes:

• New event for internal usage within package for logging errors; UnifiedAnalyticsError #167

This PR adds logging to try blocks found within the Session and LogHandler classes. We still have more try blocks within the SurveyHandler class but that will require a refactor to allow us to pass the Analytics.send method. More details in the issue below:

• Refactor SurveyHandler to use Event.analyticsException event for logging errors #232

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[eliasyishak]

This big diff is mostly a refactor to not repeat ourselves 3 times (and possibly more as we add more tools) to check the legacy opt out files

[christopherfujino]

Why only send once?

[eliasyishak]

In the log handlers case, we are checking if each log record is malformed. So in the worst case scenario, we could have 2,500 malformed log records. This check would it make it so that we don't receive tons of errors logs from just one client

Code from log handler below where send these events

    final records = logFile
        .readAsLinesSync()
        .map((String e) {
          try {
            return LogItem.fromRecord(jsonDecode(e) as Map<String, Object?>);
          } on FormatException catch (err) {
            if (!_errorEventSent) {
              _sendFunction(Event.analyticsException(
                workflow: 'LogFileStats.logFileStats',
                error: err.runtimeType.toString(),
                description: 'message: ${err.message}\nsource: ${err.source}',
              ));
              _errorEventSent = true;
            }
            return null;
            // ignore: avoid_catching_errors
          } on TypeError catch (err) {
            if (!_errorEventSent) {
              _sendFunction(Event.analyticsException(
                workflow: 'LogFileStats.logFileStats',
                error: err.runtimeType.toString(),
              ));
              _errorEventSent = true;
            }
            return null;
          }
        })
        .whereType<LogItem>()
        .toList();

[christopherfujino]

What is an "invocation" in this instance? For an analysis server session that lasts 8 hours, would we only ever send one error event, or is the LogHandler not that long-lived?

[eliasyishak]

Oh that is a good point, as it stands right now, it would be per dart process. In that case, i can rework the logic for _errorEventSent so that it gets reset every x minutes. The main purpose of this was so that one client wasn't reporting hundreds of the same error event

[christopherfujino]

Rather than using timestamps, can we rather group together operations that we expect could error multiple times, and track a single local bool errorAlreadySent for those operations?

[eliasyishak]

I think it might be even better to create an abstraction for handling errors, something like ErrorHandler that can be passed to each class created by Analytics.

This class can keep track of what events we have sent for errors and block any events we have already sent. That should centralize our error handling to one class

[christopherfujino]

Again, why only once?

[eliasyishak]

Same idea for the session handler here except we aren't dealing with the loop from the map method. With the session handler, if we have a problem with the _refreshSessionData method, then it will end up sending an error event every time we call that method, which is every time we send an event.

So if a user had 100 events sent while an instance of Analytics is alive, then we will also have 100 error events

[eliasyishak]

@christopherfujino thoughts?

[eliasyishak]

Having this try/catch block was not necessary since we are already catching the same two exceptions when we call this method

[christopherfujino]

nit about adding another test, otherwise LGTM

[christopherfujino]

Won't this just throw again and not be caught?

[eliasyishak]

Yeah this was naively assuming that the error we encounter while parsing the json was user related and not coming from the package, creating a fix for this now