Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on SKQueueManager.receivedFailedTransaction #77

Closed
Vaberer opened this issue Feb 21, 2024 · 7 comments
Closed

Crash on SKQueueManager.receivedFailedTransaction #77

Vaberer opened this issue Feb 21, 2024 · 7 comments

Comments

@Vaberer
Copy link

Vaberer commented Feb 21, 2024

Operating System: iOS 17.2.1
Device: Phone 15 Pro Max
SDK Version: Adapty 2.7.0

Crashed: Fatal Exception: NSRangeException
[__NSArrayM removeObjectsInRange:]: range {0, 1} extends beyond bounds for empty array

Fatal Exception: NSRangeException
0  CoreFoundation                 0xec69c __exceptionPreprocess
1  libobjc.A.dylib                0x2bc80 objc_exception_throw
2  CoreFoundation                 0x39228 -[__NSArrayM removeObjectsInRange:]
3  StoreKit                       0x33808 -[SKPaymentQueue _removeLocalTransaction:]
4  StoreKit                       0x2db58 -[SKPaymentQueue finishTransaction:]
5  Adapty                         0xea028 closure #1 in SKQueueManager.receivedFailedTransaction(_:) + 40 (SKQueueManager+MakePurchase.swift:40)
6  Adapty                         0x12ab0 thunk for @escaping @callee_guaranteed @Sendable () -> () (<compiler-generated>)
7  libdispatch.dylib              0x26a8 _dispatch_call_block_and_release
8  libdispatch.dylib              0x4300 _dispatch_client_callout
9  libdispatch.dylib              0xb894 _dispatch_lane_serial_drain
10 libdispatch.dylib              0xc3c4 _dispatch_lane_invoke
11 libdispatch.dylib              0x17004 _dispatch_root_queue_drain_deferred_wlh
12 libdispatch.dylib              0x16878 _dispatch_workloop_worker_thread
13 libsystem_pthread.dylib        0x1964 _pthread_wqthread
14 libsystem_pthread.dylib        0x1a04 start_wqthread

This crash occurred for App Store users.

@x401om
Copy link
Contributor

x401om commented Feb 21, 2024

Hi, @Vaberer! Thank you for the issue. According to the stack trace you have provided, it looks like this crash was occurred within StoreKit framework. How often do you observe this behaviour? Are there any other details you can provide?

@Vaberer
Copy link
Author

Vaberer commented Feb 22, 2024

Hello @x401om thanks for your reply, maybe I found the root cause, I'm also observing SKPaymentTransactionObserver in the codebase and Adapty does the same and we both are calling SKPaymentQueue.default().finishTransaction(transaction).

As I understand, I should pass true value for observerMode https://docs.adapty.io/docs/ios-observer-mode

Am. I correct? if so, I'd like to confirm my current implementation, when a user wants to buy something, I'm calling

Adapty.makePurchase(product: product) { _ in
  // No need to handle because app has it's own observer.
}

and finishing transactions are made in the app layer. We need to integrate Adapty due to analytics and pulling the products from Adapty paywalls. Is my understanding correct?

Thanks

@x401om
Copy link
Contributor

x401om commented Feb 22, 2024

@Vaberer, you are correct. If you don't want the Adapty SDK to finish transactions, you have to activate it in observer mode. It seems like StoreKit is not very reliable at finishing the same transaction twice, as we can see.

By the way, I am curious, what is the reason you want to finish transactions by yourself? Observer Mode is intended to be used as you described, but we did not expect users to use our products and the makePurchase method in that mode, since they are supposed to have their own purchase infrastructure. There is no issue if you use makePurchase, but I have to ask for the reasons, and perhaps you will consider using the Adapty SDK in full mode.

@Vaberer
Copy link
Author

Vaberer commented Feb 22, 2024

@x401om let me explain our situation and maybe you can help.

We cooperate with a marketing agency and they want us to implement Adapty for analytics, pulling products and running ab tests.

However we, originally, had our own system for managing in-app purchases and we had to make our and Adapty systems work together. Our systems also have our own analytics and logic (i.e: sending receipts to our backend) to make everything work.

One idea came to my mind:
We still add an observer SKPaymentQueue.default().add(self)
but we won't call SKPaymentQueue.default().finishTransaction(transaction).

We just need to listen to the delegate methods to send data to our backend and do our own analytics.

Is this approach correct? Will Adapty analytics and ab testing work?

Thanks.

@x401om
Copy link
Contributor

x401om commented Feb 22, 2024

@Vaberer In Observer Mode, the only difference lies in calling the finishTransaction method. You can fully rely on our infrastructure for purchases, and, of course, you can listen to the SKPaymentQueue yourself, but refrain from closing transactions.

Additionally, you can utilize the getReceipt method and the transaction property of the AdaptyPurchasedInfo object, which is the result of makePurchase.

@Vaberer
Copy link
Author

Vaberer commented Feb 23, 2024

in this case we can close the issue, thank you for your help

@Vaberer Vaberer closed this as completed Feb 23, 2024
@AlexSaraev
Copy link

Operating System: iOS 17.4.1
Device: Phone 12 Pro Max
SDK Version: Adapty 2.10.3

Fatal Exception: NSRangeException
*** -[__NSArrayM removeObjectsInRange:]: range {0, 1} extends beyond bounds for empty array

SK1QueueManager+MakePurchase.swift - Line 40 closure #1 in SK1QueueManager.receivedFailedTransaction(_:) + 40

This crash affected users of App Store. But we don't observe and don't finish the transactions, in contrast to the previous justification. All we do is use Adapty throughout the entire purchasing process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants