Fix to ensure restoreTransactions completion callback is called #150
Conversation
…s always called in the case of duplicate updatedTransaction callbacks
|
I came up with the same solution ! 👍 |
|
I have been using this version locally and confirm works. |
RMStore.podspec
Outdated
There was a problem hiding this comment.
I remember having to shorten the description for some reason.
In any case, would you mind taking this change out of the PR?
|
Thanks for fixing this @seantb. Sorry it took so long to review. Would you mind taking out the style/code formatting changes out of the PR? |
Add a Gitter chat badge to README.md
…atting and added new lines where necessary.
|
hpique, when do you expect to pull Sean's change into the main line? |
|
Some of my customers are reporting that although they attempt to restore purchases from my Mac app, the app doesn't actually recognize their prior purchases. Should this change address that issue? Sent from my iPhone
|
…s always called in the case of duplicate updatedTransaction callbacks
…atting and added new lines where necessary.
# Conflicts: # RMStore/RMStore.m
|
Sorry for the delay. I fixed the conflicts. Please lemme know if I need to do anything else to allow this pull request to be merged. |
As single commit, as the original is messy.
…icts, etc., I'm adding these manually, so the actual commits are not part of the git history, unfortunately. However this list indicates the original PR number and the author. - Add robotmedia#138 by @protikhonov. - Add robotmedia#150 by @seantb. - Add robotmedia#175 by @metasmile
…media#150 Inside RMStore, when the paymentQueue:updatedTransactions is called after a restore, a pendingRestoredTransactions counter was incremented/decremented as transactions were processed. However, in our case updateTransactions callback was called twice, so 2x the amount of transactions were added to the pendingRestoredTransactions counter. The problem was the counter was incremented twice but only decremented once for each transaction. WHen the code reached notifyRestoreTransactionFinishedIfApplicableAfterTransaction, the counter was checked but was not equal to zero, so the callback wasn't called, even though all the transactions were processed. The fix was to use a MutableSet to store transaction identifiers that were pending restore, which prevents duplicate transactions to be handled. The callback is now always called after transactions are restored.
5 participants
Inside RMStore, when the paymentQueue:updatedTransactions is called after a restore, a pendingRestoredTransactions counter was incremented/decremented as transactions were processed. However, in our case updateTransactions callback was called twice, so 2x the amount of transactions were added to the pendingRestoredTransactions counter. The problem was the counter was incremented twice but only decremented once for each transaction. WHen the code reached notifyRestoreTransactionFinishedIfApplicableAfterTransaction, the counter was checked but was not equal to zero, so the callback wasn't called, even though all the transactions were processed.
The fix was to use a MutableSet to store transaction identifiers that were pending restore, which prevents duplicate transactions to be handled. The callback is now always called after transactions are restored.