Identify the signed in user after the client is initialized

[dgilperez]

Setting up Sentry on our flutter app, we instantiate the SentryClient just by adding the dsn param and no other context as instructed. Exceptions get catched in the guarded zone and using FlutterError.onError.

Later on the the execution of the code, a user signs in, so we'd like to add that information to next errors. I don't see a client.identify method, which is the strategy crashlytics uses (what we use now) FirebaseCrashlytics.instance.setUserIdentifier(_currentUser.userId);. We can't add that context on app start, and we can't access current user since it's not global.

How should we make Sentry aware of that context at any point of the code?

[ueman]

You can do this with the following code:

Sentry.configureScope((scope) {
  scope.user = User(
    email: 'jon.doe@example.com',
    username: 'John Doe' 
  );
});

[marandaneto]

if you're using the Prerelease, that's right 👍

a preview of the docs are also live btw

https://docs.sentry.io/platforms/dart/
https://docs.sentry.io/platforms/flutter/

[dgilperez]

Thanks both!

Sidenote from the docs and sorry for not opening a new issue:

About initialization, I see the new format https://docs.sentry.io/platforms/flutter/ that is not using runZonedGuarded.

I was planning to do:

  await Sentry.init((options) async => options
      ..dsn = 'XX'
      // ..environment = 'staging'
      ..addInAppInclude('my_name'));

  runZonedGuarded(() {
    runApp(MyApp());
  }, ErrorTracker.logError);

ErrorTracker.logError has a print and a call to Sentry.captureException

Is that correct? Or should I go with

await SentryFlutter.init(
    (options) => options.dsn = 'XX',
    () {
      // Run your App
      runApp(MyApp());
    },
  );

[marandaneto]

@dgilperez if you navigate at https://docs.sentry.io/platforms/flutter/usage/advanced-usage/#tips-for-catching-errors

we run your callback given to the SentryFlutter.init method already in the runZonedGuarded, so it's done automatically, you don't need this boilerplate anymore :)

[dgilperez]

Thanks @marandaneto !

I plan to use Crashlytics and Sentry at the same time for at least one release. I want to check the differences, specially since Crashlytics does not seem to catch many of our crashes.

For that purpose we have ErrorTracker.logError do both reports, to sentry and to crashlytics.

So may I keep await SentryFlutter.init with no callback and then do the runZonedGuarded, or init Sentry, or do the callback initialization and then run a runZonedGuarded only for Crashlytics inside the callback?

[dgilperez]

Or if we were to drop crashlytics totally, then would that zoneguarded catch and report any flutter exception or otherwise?

I just did a quick test with a throw on the code, not wrapped in a try-catch, and it was not reported.

[marandaneto]

running multiple crash reporting is most probably not supported (not tested on Flutter yet), but the error handlers race each other, See a note on our Android SDK https://github.com/getsentry/sentry-java#android-note-on-multiple-crash-reporting-sdks

it's probably the same thing on Flutter, not only for Sentry but for all crash reporting.

The other thing is, some sort of errors are not captured on Debug (or if there's an attached debugger) mode due to a limitation on the Flutter error handler eg flutter/flutter#48972

Did you run on release mode? if crashlytics is not running and you did run on release mode and still didn't capture the error, please open a new issue :)

[dgilperez]

Thanks a lot @marandaneto. That flutter issues was actually quite revealing to some of the problems we've being seeing. Life-saver, even, maybe :)

Just for completeness, would you suggest moving the ensureInitialized and FlutterError.onError inside the SentryFlutter.init callback, as they suggest at the bottom of that issue?

This would be my setup in that case:

  await SentryFlutter.init(
      (options) => options
        ..dsn =
            'https://x'
      // For better groupping, change the 'example' below with your own App's package.
      // ..release = await _release()
      // ..environment = 'staging'
      , () {
    try {
      WidgetsFlutterBinding.ensureInitialized();

      FlutterError.onError = ErrorTracker.flutterOnError;

      runApp(Rosita());
    } on FirebaseException catch (e, stacktrace) {
      ErrorTracker.logException(e, stacktrace);
      print('FirebaseException: Failed with error code: ${e.code}');
      print(e.message);
    } catch (e, stacktrace) {
      ErrorTracker.logException(e, stacktrace);
    }
    // runZonedGuarded(() {
    // }, ErrorTracker.logException);
  });

[marandaneto]

@dgilperez sorry late reply, somehow missed this.

WidgetsFlutterBinding.ensureInitialized(); is already called by SentryFlutter.init as we need for some other stuff, but yes, it looks like it needs to be inside of the runZonedGuarded

I believe FlutterError.onError does not need to be inside of the runZonedGuarded, it's just a static field.

We are actually discussing about the ensureInitialized thingie in here #263 might be interesting for you to follow up.

[dgilperez]

Thanks for the reply @marandaneto - will follow the thread there.

[m-amin]

You can do this with the following code:

Sentry.configureScope((scope) {
  scope.user = User(
    email: 'jon.doe@example.com',
    username: 'John Doe' 
  );
});

Hello, where exactly place this code ?

[adrianvintu]

Update

    Sentry.configureScope((scope) {
      scope.setUser(
        SentryUser(email: 'jon.doe@example.com', username: 'John Doe'),
      );
    });