Android crash in OpenIapModule.onPurchasesUpdated: IllegalStateException "Already resumed" during requestPurchase flow

[edgarrii]

Summary

We're seeing another Android fatal crash in the OpenIAP Google purchase flow.
This one is different from the already fixed ProductManager.getOrQuery crash from #88 / #89.
The crash happens in dev.hyo.openiap.OpenIapModule.onPurchasesUpdated during the requestPurchase flow and looks like another double-resume of a coroutine continuation.

Impact

• 25 occurrences
• 25 users impacted
• fatal crash in production
• unresolved / ongoing

Environment

• react-native-iap: 14.7.12
• OpenIAP Google version resolved by react-native-iap: 1.3.28
• Android only
• Seen in production in purchase flow (ProxyBillingActivity visible in app context)

Error

IllegalStateException: Already resumed, but proposed with update []

Stacktrace

at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1133)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:567)
at java.lang.reflect.Method.invoke(Method.java)
at android.app.ActivityThread.main(ActivityThread.java:8641)
at android.os.Looper.loop(Looper.java:313)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Handler.handleCallback(Handler.java:938)
at com.android.billingclient.api.zzan.run(...)
at com.android.billingclient.api.BillingClientImpl.zzV(...)
at dev.hyo.openiap.OpenIapModule.onPurchasesUpdated(...)
at dev.hyo.openiap.OpenIapModule$requestPurchase$1$purchases$1$10$1.invoke(...)
at dev.hyo.openiap.OpenIapModule$requestPurchase$1$purchases$1$10$1.invoke(...)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(...)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core$default(...)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core(...)
at kotlinx.coroutines.CancellableContinuationImpl.b(...)

Suspected root cause

This looks like a separate double-resume race in the purchase flow, not in product querying.

From the current Android OpenIAP purchase logic, requestPurchase stores a continuation callback in something equivalent to:

suspendCancellableCoroutine<List<Purchase>> { continuation ->
  currentPurchaseCallback = { result ->
    if (continuation.isActive) {
      continuation.resume(result.getOrDefault(emptyList()))
    }
  }

  // launch billing flow...
}

Then onPurchasesUpdated(...) later invokes that callback:

currentPurchaseCallback?.invoke(Result.success(mapped))
// ...
currentPurchaseCallback = null

Because currentPurchaseCallback is cleared only after invocation, it seems possible that onPurchasesUpdated(...) may trigger the same callback more than once before it is nulled out, or that multiple billing callbacks race with each other and attempt to resume the same continuation twice.

That would match this crash:

IllegalStateException: Already resumed, but proposed with update []

Expected behavior

The purchase flow should never crash the app if Google Play Billing triggers repeated or late callbacks.

If the continuation has already been resumed or cancelled, subsequent callbacks should be ignored safely.

Actual behavior

The app crashes with a fatal IllegalStateException from CancellableContinuationImpl during purchase handling.

Reproduction notes

We do not yet have a stable local repro, but production data suggests it happens during the purchase flow after Billing launches:

1. Start requestPurchase
2. Billing flow opens (ProxyBillingActivity)
3. onPurchasesUpdated(...) is triggered
4. The same continuation appears to be resumed more than once
5. App crashes

Suggested direction

It may help to make the purchase callback single-use before invoking it, for example by capturing and nulling it first:

val callback = currentPurchaseCallback
currentPurchaseCallback = null
callback?.invoke(Result.success(mapped))

or by otherwise guaranteeing that the same continuation cannot be resumed twice even if multiple billing callbacks arrive.

[hyochan]

Confirmed root cause and fix is up in #95.

Why this crashes

requestPurchase stored the resume lambda in a shared mutable field (currentPurchaseCallback) and only nulled it out at the very end of onPurchasesUpdated. Between the moment we invoke the lambda and the line that clears the slot:

• onPurchasesUpdated can be re-fired by Play Billing (duplicate updates do happen in the wild, especially around ProxyBillingActivity lifecycle), or
• one of the early-return paths inside requestPurchase (offer-token mismatch, missing SKU, query-product failure, etc.) invokes the callback without then nulling the slot — so a later billing event still sees a non-null lambda and invokes it again.

The lambda's if (continuation.isActive) continuation.resume(...) guard is not atomic with resume() itself. Two callers can both pass the isActive check and both proceed to resume(), which produces exactly the crash you reported:

IllegalStateException: Already resumed, but proposed with update []
  at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(...)
  at dev.hyo.openiap.OpenIapModule$requestPurchase$1$purchases$1$10$1.invoke(...)
  at dev.hyo.openiap.OpenIapModule.onPurchasesUpdated(...)

The fix

Your suggested direction was correct — make the callback single-shot by nulling it out before invoking, not after. #95 takes the same idea and makes it race-free by replacing the field with an AtomicReference and routing every invocation through:

private fun consumePurchaseCallback(result: Result<List<Purchase>>) {
    currentPurchaseCallback.getAndSet(null)?.invoke(result)
}

getAndSet(null) is atomic, so even if two threads race (or onPurchasesUpdated is reentered before the previous call finishes), only the first one gets a non-null lambda; the rest get a no-op. The same change is applied symmetrically to both the Play and Horizon variants, and the slot is also cleared on continuation cancellation (via compareAndSet so a cancelled older request can't null out a newer one) so a late billing event after a cancelled request can't resurrect the old continuation.

Why this structurally prevents the crash

Since we don't have a local repro (25 users / 25 events from production), it is worth walking through why this fix removes the precondition for the crash rather than just patching a symptom.

The stack trace tells us exactly one thing: for IllegalStateException: "Already resumed" to throw, continuation.resume(...) must be called at least twice on the same continuation. And in this module, resume() is called from exactly one place — inside the currentPurchaseCallback lambda (verified by grep). So the question reduces to:

Can the lambda be invoked more than once?

Before the fix — yes, under the race conditions listed above (duplicate onPurchasesUpdated delivery, early-return paths leaving the slot populated, cross-thread delivery with non-atomic isActive/resume).

After the fix — no, structurally. AtomicReference.getAndSet(null) is an atomic read-modify-write defined by the JMM. Exactly one caller receives the lambda; every subsequent caller receives null and becomes a no-op. There is no interleaving where two callers both get a non-null lambda. Therefore the lambda can be invoked at most once, so resume() is called at most once, so the IllegalStateException precondition is unreachable.

Edge cases checked

Scenario	Behavior after fix
onPurchasesUpdated fires twice sequentially	First call consumes, second is no-op ✅
Two threads race into onPurchasesUpdated	getAndSet ensures only one wins ✅
Early-return path invokes callback, billing fires later	Slot already null, billing call is no-op ✅
Continuation cancelled mid-flight, billing fires late	isActive false and slot cleared ✅
Two concurrent requestPurchase() calls	No crash (compareAndSet on cancellation preserves the newer callback). Older continuation may leak — pre-existing issue, separate concern

Honest limitations

• No local repro — this is a production-only crash tied to specific device/timing conditions. The structural argument above is the reason for confidence, but final confirmation requires Crashlytics/Sentry data after release.
• Version reach — you are on react-native-iap@14.7.12 with openiap-google@1.3.28. This fix lands in the OpenIAP monorepo and reaches users via react-native-iap@15.x+ (and the other framework libraries at the versions listed below). The 14.x line does not receive this fix.
• Future regressions — if a future change introduces another code path that calls continuation.resume() outside this lambda, the guarantee weakens. The AtomicReference pattern is now the contract; future edits should preserve it.

---

Note: This repository (OpenIAP monorepo) handles development for all framework libraries from the versions listed below. For earlier versions, refer to the archived individual repositories.

• react-native-iap v15.0.0+
• expo-iap v4.0.0+
• flutter_inapp_purchase v9.0.0+
• godot-iap v2.0.0+
• kmp-iap v2.0.0+