Warning of Possible Unhandled Promise Rejection from purchaseErrorListener

[chetstone]

Version of react-native-iap

3.0.3

Version of react-native

0.59.10

Platforms you faced the error (IOS or Android or both?)

Android

Expected behavior

No unhandled promise warning

Actual behavior

09-03 16:42:41.214 20367 21085 I ReactNativeJS: 'purchaseErrorListener', { debugMessage: '', responseCode: 1 }
09-03 16:42:43.254 20367 21085 W ReactNativeJS: Possible Unhandled Promise Rejection (id: 0):
09-03 16:42:43.254 20367 21085 W ReactNativeJS: Error: Payment is Cancelled.
09-03 16:42:43.254 20367 21085 W ReactNativeJS: createErrorFromErrorData@http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2108:26
09-03 16:42:43.254 20367 21085 W ReactNativeJS: http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2060:51
09-03 16:42:43.254 20367 21085 W ReactNativeJS: __invokeCallback@http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2627:23
09-03 16:42:43.254 20367 21085 W ReactNativeJS: http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2358:34
09-03 16:42:43.254 20367 21085 W ReactNativeJS: __guard@http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2531:15
09-03 16:42:43.254 20367 21085 W ReactNativeJS: invokeCallbackAndReturnFlushedQueue@http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2357:21
09-03 16:42:43.254 20367 21085 W ReactNativeJS: invokeCallbackAndReturnFlushedQueue@[native code]

Tested environment (Emulator? Real Device?)

Real Device

Steps to reproduce the behavior

Build Example App on the 3.0.x branch. Run on device, touch Get Products, then touch Purchase android.test.canceled

[haikov]

As I understand it happens due to this line: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapModule.java#L506 They used in a few other places as well.

I can't understand why this functions are being called after error event was fired. Looks like there's a combination of 2 approaches used here.

The new promise is being create on each initialization and then it's resolved or rejected depending on the operation results along with sending events via DeviceEventManagerModule.

But as I understood from the docs, the only way of communication with the library is via events, promises are deprecated now.

Maybe I don't get something correctly, but from my point of view, the library shouldn't reject promises when sending error events.

@hyochan Any other ideas? I'm ready to contribute, just want to understand that I'm moving into the correct direction.

[hyochan]

@gaykov You are right. Looks like this is a side effect in an effort to support both event and promises. Hoping for improvement from your PR 🔨

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open. Thank you for your contributions.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.