Datadog experienced a PlatformException - No logger available with handle 919809f1-a502-461e-b7f1-1735b75a1e16 in call to log.

[rohith-alphanso]

Thanks for taking the time for reporting an issue!

Describe what happened
I tried to my app on Iphone SE 3rd generation simulator I am getting this exception

flutter: [Datadog 🐶🔥 ] Datadog experienced a PlatformException - No logger available with handle 919809f1-a502-461e-b7f1-1735b75a1e16 in call to log.
flutter: [Datadog 🐶🔥 ] This may be a bug in the Datadog SDK. Please report it to Datadog.

It doesn't happen with my other simulator (Iphone 15 Pro Max) and real device (Iphone Xs Max)

Steps to reproduce the issue:

• Create a new flutter project
• Run it on Iphone SE 3rd gen

Describe what you expected:

• Expected to run the app successfully on Iphone SE

Additional context

• Dart/Flutter version: 3.16.0
• Android/iOS OS version: 17.0
• Device Model: Iphone SE 3rd Gen
• Datadog SDK version:

  datadog_flutter_plugin: ^2.1.0
  datadog_grpc_interceptor: ^1.0.0
  datadog_tracking_http_client: ^2.0.0

• Versions of any other relevant dependencies:

[fuzzybinary]

Hi @rohith-alphanso thanks for reporting!

2.1.0 added a finalizer to Loggers to remove them when Dart no longer can reach them. I'm curious why the finalizer is working differently on the iPhone SE simulator....

Is this reproducable with a simple case? Can you give me a simple example project to see if I can figure out why Dart might be finalizing the logger?

[rohith-alphanso]

Hi @rohith-alphanso thanks for reporting!

2.1.0 added a finalizer to Loggers to remove them when Dart no longer can reach them. I'm curious why the finalizer is working differently on the iPhone SE simulator....

Is this reproducable with a simple case? Can you give me a simple example project to see if I can figure out why Dart might be finalizing the logger?

We are facing this exception, with 2.0.0 as well, we will try to have a simple repro

[fuzzybinary]

@rohith-alphanso That is incredibly strange, as prior to 2.1.0 we didn't remove loggers from the registry. I'll continue looking into this but please let me know if you find a simple repro.

[fuzzybinary]

@rohith-alphanso I can't reproduce here with my simple examples. I'm wondering if there's something weird in your initialization. Are you awaiting DatadogSdk.initialize before creating a logger?

[rohith-alphanso]

@rohith-alphanso I can't reproduce here with my simple examples. I'm wondering if there's something weird in your initialization. Are you awaiting DatadogSdk.initialize before creating a logger?

yes,

final datadogConfiguration = DatadogUtils.getDatadogSdkConfiguration();
  await DatadogSdk.instance
      .initialize(datadogConfiguration, TrackingConsent.granted);

[rohith-alphanso]

@rohith-alphanso I can't reproduce here with my simple examples. I'm wondering if there's something weird in your initialization. Are you awaiting DatadogSdk.initialize before creating a logger?

static final _datadogLogger = DatadogLogger(
   InternalLogger(),
   DatadogLoggerConfiguration(
     networkInfoEnabled: true,
   ),
 );

 static DatadogConfiguration getDatadogSdkConfiguration() {
   final datadogEnvironment = _getDatadogEnvironment();

   return DatadogConfiguration(
     service: 'XXXXX',
     clientToken: _clientToken,
     env: datadogEnvironment,
     site: _datadogSite,
     nativeCrashReportEnabled: true,
     firstPartyHosts: _firstPartyHosts,
     uploadFrequency: UploadFrequency.frequent,
     rumConfiguration: DatadogRumConfiguration(
       applicationId: _applicationId,
       viewEventMapper: DatadogSessionIdRetriever.viewEventMapper,
     ),
   )..enableHttpTracking();
 }; 
 
 final datadogConfiguration = getDatadogSdkConfiguration();
 await DatadogSdk.instance
     .initialize(datadogConfiguration, TrackingConsent.granted);

• This is how we are defining logger in our application

[fuzzybinary]

@rohith-alphanso I'll confirm, but my guess is that the static initialization of _datadogLogger is running before DatadogSdk.instance.initialize, which means that the MethodChannels aren't available to create the actual logger when you call DatadogSdk.instance.logs?.createLogger. I'm not 100% sure how you get an logger Id in this scenario, but I'll try to recreate and see.

Hopefully your call to DatadogSdk.instance.initialize in main?

[fuzzybinary]

Oh, actually, this is improper usage of this API. InternalLogger in an internal type (and marked as such in the documentation). The constructor for DatadogLogger is also internal, but not marked as so via attributes (I will fix that).

To create loggers, it's expected you will call DatadogSdk.instance.logs?.createLogger after initializing Datadog.

[rohith-alphanso]

@rohith-alphanso I'll confirm, but my guess is that the static initialization of _datadogLogger is running before DatadogSdk.instance.initialize, which means that the MethodChannels aren't available to create the actual logger when you call DatadogSdk.instance.logs?.createLogger. I'm not 100% sure how you get an logger Id in this scenario, but I'll try to recreate and see.

Hopefully your call to DatadogSdk.instance.initialize in main?

yes

Future<void> initializeApp() async {
  WidgetsFlutterBinding.ensureInitialized();

  final datadogConfiguration = DatadogUtils.getDatadogSdkConfiguration();
  await DatadogSdk.instance
      .initialize(datadogConfiguration, TrackingConsent.granted);

  FlutterError.onError = (final details) {
    FlutterError.presentError(details);
    DatadogSdk.instance.rum?.handleFlutterError(details);
  };

  PlatformDispatcher.instance.onError = (final error, final stackTrace) {
    DatadogSdk.instance.rum?.addErrorInfo(
      error.toString(),
      RumErrorSource.source,
      stackTrace: stackTrace,
    );
    return true;
  };
 }

This initializeApp is called in the main method

[fuzzybinary]

@rohith-alphanso See above though. You cannot create a DatadogLogger from it's constructor. It should be marked as @internal. Use DatadogSdk.instance.logs?.createLogger instead after Datadog is initialized.

[fuzzybinary]

@rohith-alphanso Did you ever get this resolved?

[rohith-alphanso]

Yes

…

On Wed, 3 Jan 2024, 8:40 pm Jeff Ward, ***@***.***> wrote: @rohith-alphanso <https://github.com/rohith-alphanso> Did you ever get this resolved? — Reply to this email directly, view it on GitHub <#530 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDTQBN2SYX76WFW7LV6TAI3YMVYFTAVCNFSM6AAAAABATJ4BBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGUZDIMRZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>