Awaiting initialize in Zendesk Messaging Flutter Breaks Hot Reload

[AtamerSahin]

When calling ZendeskMessaging.initialize() with await, the hot reload feature in Flutter stops working. The app enters what seems to be an infinite await state, preventing hot reload from functioning correctly.

Steps to Reproduce:

1. Call await ZendeskMessaging.initialize(yourChannelKey); in the main initialization process.
2. Run the app and try using hot reload.

Expected Behavior:
The app should initialize Zendesk Messaging and allow hot reload to function normally.

Actual Behavior:
The app appears to enter an infinite await state, breaking hot reload functionality.

Platform:
• Android
• iOS

Additional Notes:
This issue does not occur if initialize() is called without await. However, this workaround is not ideal as it prevents proper async handling of initialization.

[plchekspend]

Hey @AtamerSahin I'm using below code for the same and i've not encounter the hot reload issue.

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
      try {
        final String iosChannelKey = Env.iosKey;
        final String androidChannelKey = Env.androidKey;
        ZendeskMessaging.initialize(
          androidChannelKey: androidChannelKey,
          iosChannelKey: iosChannelKey,
        );
      } catch (err) {
        // print;
      }
    runApp(const App());
} 

[plchekspend]

Else you can try this code,

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
    final String iosChannelKey = Env.iosKey;
        final String androidChannelKey = Env.androidKey;
  await Future.wait(<Future<void>>[
        ZendeskMessaging.initialize(
          androidChannelKey: androidChannelKey,
          iosChannelKey: iosChannelKey,
        );
  ]).whenComplete(() {
    runApp(const App());
}

[AtamerSahin]

Hey @AtamerSahin I'm using below code for the same and i've not encounter the hot reload issue.

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
      try {
        final String iosChannelKey = Env.iosKey;
        final String androidChannelKey = Env.androidKey;
        ZendeskMessaging.initialize(
          androidChannelKey: androidChannelKey,
          iosChannelKey: iosChannelKey,
        );
      } catch (err) {
        // print;
      }
    runApp(const App());
} 

You are not awaiting the function

[plchekspend]

Hey @AtamerSahin I'm using below code for the same and i've not encounter the hot reload issue.

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
      try {
        final String iosChannelKey = Env.iosKey;
        final String androidChannelKey = Env.androidKey;
        ZendeskMessaging.initialize(
          androidChannelKey: androidChannelKey,
          iosChannelKey: iosChannelKey,
        );
      } catch (err) {
        // print;
      }
    runApp(const App());
} 

You are not awaiting the function

I don't think it's necessary to await the initialization, as it's working perfectly fine in both my Android and iOS apps without any issues.

[AtamerSahin]

You’re right that in many cases, calling ZendeskMessaging.initialize without await works fine, especially when using static keys like Env.iosKey and Env.androidKey. However, in some scenarios, the keys need to be fetched from a secure service before initialization.

Since fetching keys is an asynchronous operation, if we don’t await it, the initialization might start before the keys are available, leading to potential issues. That’s why, in cases where the keys are retrieved dynamically, we need to ensure the initialization happens only after we have the keys by using await.

Hope that clarifies it

[plchekspend]

Got it! In your case, remove the initialization code from the main method and place it in the initState of specific page using a custom function but make sure it's called only once. This way, you can avoid the functionality breaking during hot reload. Alternatively, you can call that function from your preferred state management, but make sure it's called only once.

[AtamerSahin]

Got it! In your case, remove the initialization code from the main method and place it in the initState of specific page using a custom function but make sure it's called only once. This way, you can avoid the functionality breaking during hot reload. Alternatively, you can call that function from your preferred state management, but make sure it's called only once.

I see your point, but wouldn’t it be more reliable to explicitly await the initialization? Ensuring that the service call completes before proceeding is crucial for security in my case.

You mentioned using await Future.wait([...]), but I haven’t tested it yet. Does this approach work reliably without breaking hot reload? Also, since Future.wait is usually used for running multiple futures in parallel, wouldn’t a direct await be a clearer approach for ensuring execution order? Let me know what you think 🙏

[plchekspend]

which flutter SDK you were using?
I have tested with 3.24.5 and upper SDK's everything is working fine with hot reload in my case.
Also I noticed this that once the zendesk is initialized then it wan't initialize again, console print with this message

I/System.out(20040): [ZendeskMessagingPlugin] - Messaging is already initialized!

Maybe your API is taking more time to get the keys due to that you felt that hot reload is breaks.

[AtamerSahin]

Hello again, your suggestion still doesn’t address the root issue.

If I skip await, and immediately call ZendeskMessaging.initialize() before those values are ready, it leads to race conditions — especially when doing things like revalidate(), and Zendesk.initialize() in sequence. The order gets broken, and initialization happens with invalid or missing keys.

Also, this isn’t just about hot reload. Hot restart completely breaks if you await ZendeskMessaging.initialize() in main(). The app hangs before it reaches runApp(), confirmed on:
• Flutter 3.19.6
• Flutter 3.22.2
• Flutter 3.29.3 (my current version)
None of that fixes it — because the SDK still gets stuck during app boot if await is used.

Another weird behavior:
Zendesk SDK silently caches login/token somewhere internally. Even after a full restart, it restores the user session without explicit handling. This causes unexpected behavior unless you force a logout or reinit flow manually.

Always need to initialize with logout method.

[AtamerSahin]

One more important question:

When calling ZendeskMessaging.initialize(), how can we properly handle initialization failures?

Currently on iOS, if something goes wrong during initialization (for example wrong channel key, network issues, internal SDK errors), there is no proper error thrown that we can catch or handle.
• initialize() just seems to hang silently or return without giving any indication of failure.
• No exception, no callback, no visible status.
• Therefore, i can’t programmatically detect if Zendesk failed to initialize and fallback gracefully.

Is there any documented way without message handler?

[martipello]

i find awaiting the initialization to not hang the UI but it actually never awaits it,
raised issue #84