Flutter iOS端RevenueCat间歇性抛出NSInternalInconsistencyException异常排查

The Error Log #

[Purchases] - INFO: There is no singleton instance. Make sure you configure Purchases before trying to get the default instance.
*** Assertion failure in +[RCCommonFunctionality getPurchaserInfoWithCompletionBlock:], RCCommonFunctionality.m:118
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'You must call setup first.'
*** First throw call stack: (0x1a0379654 0x1a009bbcc 0x1a027c6ec 0x1a06c216c 0x1032908ac 0x1032cdf9c 0x1032cc0d4 0x105c3ae30 0x1053ef758 0x1056d58b4 0x1053f90ec 0x1053fb818 0x1a02f8134 0x1a02f7e50 0x1a02f752c 0x1a02f253c 0x1a02f1ba8 0x1aa461344 0x1a442d3e4 0x102c4069c 0x1a01798f0)
libc++abi.dylib: terminating with uncaught exception of type NSException

• thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  frame #0: 0x00000001a016ed88 libsystem_kernel.dylib__pthread_kill + 8 libsystem_kernel.dylib__pthread_kill:
  -> 0x1a016ed88 <+8>: b.lo 0x1a016eda4 ; <+36>
  0x1a016ed8c <+12>: stp x29, x30, [sp, #-0x10]!
  0x1a016ed90 <+16>: mov x29, sp
  0x1a016ed94 <+20>: bl 0x1a014dad0 ; cerror_nocancel
  Target 0: (Runner) stopped.
  Lost connection to device.

Context #

This is an intermittent issue (doesn't happen every time). I already configure the Purchases instance right after the user completes authentication and gets their UID:

await Purchases.setDebugLogsEnabled(isDebugEnabled);
await Purchases.setup(kRevenueCatApiKey, appUserId: uid);

I'm confused why this still pops up occasionally—most of the time the feature works fine. Did I miss any configuration steps?

Possible Solutions & Debugging Steps #

• Fix async race conditions
  The most likely culprit is a race where some code tries to access RevenueCat's singleton before your setup call finishes. Even with await, if another part of your app (like an early-loading subscription status check) triggers PurchaserInfo requests without waiting for the auth + setup flow to complete, you'll hit this error intermittently.
  Try wrapping all RevenueCat operations in a check for a "setup complete" flag, or use state management (Provider, Riverpod, etc.) to block access until setup is done.

• Guard against early widget initialization
  If you're using Flutter, widgets in your tree might initialize before the auth + setup flow finishes. For example, a subscription screen that fetches purchaser info in initState could run before Purchases.setup completes.
  Use a FutureBuilder or conditional rendering to only load subscription-related UI once setup is confirmed.

• Ensure setup runs exactly once
  Intermittent crashes can happen if setup is called multiple times accidentally, or if a second call starts before the first completes. RevenueCat setup should only run once per app session.
  Add a guard flag to prevent duplicate calls:

  static bool _isPurchasesSetup = false;
  
  // Inside your auth completion handler
  if (!_isPurchasesSetup) {
    await Purchases.setDebugLogsEnabled(isDebugEnabled);
    await Purchases.setup(kRevenueCatApiKey, appUserId: uid);
    _isPurchasesSetup = true;
  }
  

• Test auth flow edge cases
  Fast re-authentication or cached auth tokens might trigger setup before the previous session's Purchases instance is cleared. Test scenarios where the user logs out and back in quickly to replicate the issue.
  Call Purchases.logOut() when the user signs out to reset the singleton before re-running setup.

• Crank up verbose logs
  Since you already have debug logs enabled, increase verbosity to track exactly when setup is called vs when the PurchaserInfo request fires. This will help you pinpoint the exact race condition.

内容的提问来源于stack exchange，提问作者Zenko