OnPurchaseFailed fails to get called with Failed to purchase unknown product

Hello.
Currently running 2.2.6 but had this same occurrence in 2.2.5. Running a Samsung Galaxy Note5 on Android 5.1.1
While edge-case bugtesting my application with UnityIAP we ran into this weird issue with Google Play. I specifically tested launching the app with a wifi-connection, and then disconnected after it finished launching and attempted to make a purchase (to ensure a timeout successfully occurs).

With one of our products the time out occurred successfully, and OnPurchaseFailed() was called allowing us to back out of our UI "Please wait while we yada yada" display.
But weirdly enough, with the other product it completely failed to time out and didn't call OnPurchaseFailed().

Instead we received

Bigger log to show from click to fail:

And since OnPurchaseFailed() was not called, our app was basically softlocked now, as the "Please wait" overlay is meant to lock out any further input while we wait to hear from the store.

I'm not sure what happened, as the product in question was correctly being retrieved in init:

If I quit and relaunched the application, this error would still occur with this same particular product.


However, I eventually reconnected to wifi and attempted the purchase but backed out. Then I went offline again, and now it finally began timing out correctly. It seems to behave as expected. So all I can possibly guess at here is something regarding the purchase ID was corrupted.
If you told me to recreate this state I wouldn't really know how to go about it.

SO, after all that blabbing what I'm here to say is we need a hook for "Failed to purchase unknown product", preferably it would be routed through OnPurchaseFailed().
Even if this is a strange edgecase bug to begin with, it should still be expected to fail out of it gracefully.

 

This appears to be possibly related to this thread, which I didn't notice until just now
https://forum.unity.com/threads/iap...rereason-unknown-android-google-play.1035271/

Also I am able to re-enter the bad state that products the 'unknown product' error somewhat consistently, if I freshly install the app (via Google Play Internal Testing), launch it, and then go offline a couple seconds after it is launched and then attempt a purchase.

 

If you are still seeing this issue, please provide specific steps to reproduce and any differences in the products that you are using. There should be no differing behavior between products of the same type (consumable, non-consumable, subscription)

 

Yes, I can still reproduce it very reliably now, granted via some odd interference.
1) Be connected to Wifi
2) I clear the Google Play store application's Data & Cache in Android (I do this b/c GP seems to cache purchase data)
3) I clear the Data & Cache for my application as well
4) I launch my application
5) I disable Wifi when I get my application's main menu, which is about 5 seconds after the Unity splash is finished and we are likely well initialized at this point. I verify this b/c I see the product data showing in the adb logcat
6) I attempt to invoke a purchase with one of my IAP, and get unknown produce returned, thus softlocking my app.


While the clearing of the Google Play store cache seems edgecase, I'd like to point out this situation occurred naturally with me when I first ran into it. It was on a new Google account freshly signed into this device, so likely similar circumstances.

If a video call would be useful here, feel free to reach out to me in PM. Or a video recording at least.

 

@skullthug We will look into this. In the past, we have recommended that the user check the internet connection themselves when they need to. We wanted to avoid checking every time an IAP call is made for performance reasons.

 

Right, but what about routing the unknown product error into the OnPurchaseFailed() callback? So I can have a hook to rely on and stop softlocking the app.
As far as I can tell there's nothing called when encountering unknown product right now, so I'd need to do something hacky to try and work around it.

 

We will look into this also.