Just a question about the need for the yield functions... PaywallActivity changes make sense but just a question.

The changes in PaywallActivity make sense, but looking at the original report, they are not using the PaywallActivity...

This is a simplified version of their code:

var purchaseCompleted by remember { mutableStateOf(false) }

Paywall(
    options = PaywallOptions.Builder(
        dismissRequest = {
            // Suppress auto-dismiss after purchase so we can run
            // post-purchase logic (e.g. show a link-account sheet)
            // and dismiss manually when ready.
            if (!purchaseCompleted) onCloseClick()
        },
    )
        .setOffering(offering)
        .setListener(object : PaywallListener {
            override fun onPurchaseCompleted(
                customerInfo: CustomerInfo,
                storeTransaction: StoreTransaction,
            ) {
                purchaseCompleted = true
                viewModel.onPurchaseCompleted(customerInfo)
            }

            override fun onRestoreCompleted(customerInfo: CustomerInfo) {
                purchaseCompleted = true
                viewModel.onRestoreCompleted(customerInfo)
            }
        })
        .build(),
)

The yield changes I am a bit more hesitant about, specially after looking at their code. It’s true that if they are doing any async work in viewModel.onPurchaseCompleted, the yield would let that work run on the main thread before we call options.dismissRequest(). But notice that they set purchaseCompleted = true synchronously in the listener, before doing anything else. So by the time dismissRequest() fires, the guard already evaluates to false and onCloseClick() is suppressed yield or no yield, their pattern would work the same independently of the yields.

The other concern is the one I raised earlier: yield only flushes one level of Handler.post. If the listener’s posted work itself posts more work (or hops to a different dispatcher), we’re back to racing the dismiss. If we do want a first-class story for "finish my post-purchase flow, then dismiss," I think that deserves an explicit API (e.g. an opt-out flag or a completion signal to the listener) rather than relying on yiel based timing.

Stepping back a bit, the customer says: "the paywall should stay presented (or at least not report 'dismissed') until we finish follow-up steps and then dismiss it." But the SDK doesn’t actually dismiss anything itself, the only thing it does after purchase is call options.dismissRequest(), and what happens from there is entirely up to the developer's lambda. With their guard in place (the check for purchaseCompleted), the lambda is a no-op and the paywall should stay presented. The "not report dismissed" wording makes me think they’re misinterpreting the callback firing as the SDK dismissing them, when it isn’t.

My suggestion: keep the structural change in PaywallActivity because I think it makes sense and drop the yields (since I think it won't fix their probelm anyways). The actual issue is more likely either (a) something in their viewModel.onPurchaseCompleted is unmounting the paywall (navigation, parent state change), or (b) they’re misreading the dismissRequest callback as the dismissal itself.

Not sure how easy it would be, would it be worth trying to write a failing test on main using Paywall() composable that reproduces the report? If we can’t reproduce it, that strengthens the case that the issue is in their app code, not ours.