Service name not respected

[btrautmann]

Thanks for taking the time for reporting an issue!

Describe what happened
We're noticing that the service name passed to the DdSdkConfiguration constructor is not respected, and the resulting service name ends up being the application's package name.

Steps to reproduce the issue:

Build an app using the plugin on Android and pass serviceName as foo to the aforementioned constructor, and initialize the SDK. When querying in Datadog, this service name does not show up but the application id (e.g com.application) does.

    final datadogConfiguration = DdSdkConfiguration(
      clientToken: _clientToken,
      serviceName: 'mobile', // This ends up being application ID on backend
      env: appConfiguration.environmentString,
      trackingConsent: TrackingConsent.granted,
      site: DatadogSite.us1,
    )..additionalConfig.addAll(additionalConfig);

    await _datadogSdk.initialize(datadogConfiguration);

Describe what you expected:

The serviceName passed to the constructor should be respected/persisted on the underlying native SDK.

Additional context

• Dart/Flutter version: Flutter (Channel stable, 2.10.4, on macOS 12.4 21F79 darwin-arm, locale en-US), Dart version 2.16.2
• Android/iOS OS version: Android 9
• Device Model: Moto X4
• Datadog SDK version: 1.0.0-beta.2
• Versions of any other relevant dependencies: N/A

[btrautmann]

I'll work on verifying the same behavior occurs on iOS.

[fuzzybinary]

Hi @btrautmann,

Thanks for reporting this!

It looks like when I performed a refactor to support Web, I accidentally stopped sending the serviceName down to native mobile. I'm verifying it is indeed broken on both platforms, but from looking at the refactor it appears it will be.

Is this blocking any work on your side or will it prevent integration?

[btrautmann]

Is this blocking any work on your side or will it prevent integration?

Thankfully it's not a blocker, since we're currently using the existing community supported plugin, but this blocks us from migrating to the first party supported plugin, since we want to keep the serviceName consistent during the migration.

[fuzzybinary]

This is now fixed and deployed in 1.0.0-beta.3

[btrautmann]

I verified this is working in 1.0.0-beta.3. Thanks @fuzzybinary!