Solved

Randomly and false-zero-Entitlements returned from purchaseProduct:withCompletion


Userlevel 3
Badge +8

Hi @taquitos  With the latest 4.0.0-Beta.3, the return from purchaseProduct:withCompletion can have zero entitlement even though it is not true.

I can’t reproduce while in debug mode (randomly happens outside the debugger).

Attached is a txt file with a log of successful return (I see some errors but not sure how to cancel them).

Thanks,

 

icon

Best answer by Andy 14 January 2022, 19:45

View original

69 replies

Userlevel 3
Badge +8

I am closing the issue, never been so excited about a bug being crushed. 
you guys rock. 
@Andy warm hugs 🤗 

Userlevel 4
Badge +8

@imougy I’m so glad to hear that! What a great way to start the week! 😃 I’m so happy we could help!

 

We’ll get the docs updated, hopefully we’ll save others from running into the same thing.

Thanks so much for your patience and help in figuring out what was going on! 

Don’t hesitate to get in touch again if you need any further assistance! 

 

Userlevel 3
Badge +8

I am thrilled to write this.  Since relocating the initialization to the root view controller there was zero incident of nil customerInfo.  @Andy, I can’t thank you enough for the 20 minutes code review, I wouldn’t have done it without it.

Please update the documentation to enforce this, otherwise apps will get in trouble for sure  

I will close the issue in few days, just because the majority of Stocks Live users will upgrade this week. 
@Andy and the rest of the team @cody, @taquitos, @Jacob Eiting, you guys are awesome, thank you so much for your time and experience, RevenueCat is one of the best companies I have ever worked with and of course it is because of the people and the founders. 

Userlevel 3
Badge +8

This is awesome @Andy , thank you so much for your time and your suggestion.  I am making a release now and I feel good about it.  I am moving the initialization of the SDK to the root controller (instead of didFinishLaunchingWithOptions).

I will report back after one week to gather more data.

🙏

 

Userlevel 4
Badge +8

For anyone reading this, @imougy and I had a live session and we’re currently suspecting that the underlying issue might be the change in pre-warming behavior in iOS 15, and it’s related bugs: 

 

As for ways of working around this, it seems like the suggested approach is to move the SDK configuration to the initialization of the root VC. 

I’d also advise to move related code (like reading from the keychain), for the same reason. 

It was a pleasure chatting with you @imougy! Hope this helps, and definitely let me know how it goes! 

Userlevel 3
Badge +8

Users have the latest iOS 15.2. I am one of them. 

Userlevel 4
Badge +8

Awesome! I’ll DM you to coordinate the exact date / time. 

 

Also, do you happen to know the OS version in use by the folks who’re still facing the issue? I think the date formatter we’re using might have some issues with iOS 11.0-11.2

Userlevel 3
Badge +8

@Andy sounds good tomorrow anytime.  I am PST time. Thank you so much.

Userlevel 4
Badge +8

@imougy let’s hold off from using the branch in that case, and set up a coding session. Do you have some time tomorrow or early next week? What timezone are you in? 

Userlevel 3
Badge +8

I have no way to reproduce, it is pure random. What I can do is grab this branch and make a new App Store binary and see if users complain.  Btw, beta 8 reduced the issue by a lot but it still happens. 
what do you think? Should I grab this branch and make a new App Store release?

Userlevel 4
Badge +8

@imougy I’ve made a branch called fix/name_conflicts_on_foundation_extensions, which adds a prefix to every single internal extension in our SDK, to make absolutely sure that no conflicts can happen. 

 

If you have a way to reproduce this issue, would you mind giving the branch a shot to see if it solve it? 

Userlevel 4
Badge +8

@imougy update here: I found a few extensions where we’re not adding prefixes or necessarily disambiguating our extensions from others, which might cause conflicts. 

I’m going to work on an update to remove all ambiguity, which might solve it. 

Would you be willing to give it a shot when I’m done? 

Also, have you found any way to consistently reproduce this? Perhaps by changing regions on your device? 

And yes, having some information on the date extensions would be super helpful. Also, if you have any extensions on date formatters in particular, since those seemed to be the conflict with DataDog’s SDK. 

 

Userlevel 3
Badge +8

I am using swift manager to install Hero, Firebase, RevenueCat. I can share with you the date extension, but I don’t think this is the reason because the issue happens to all users, me included and I am in USA region. 
please feel free to set up the love coding session and I can also send you my date extensions if you like. 

Userlevel 4
Badge +8

@imougy I’m going through all the code, logs and comments to get a better understanding, and would love to set up a live coding session so we can finally figure this out. 

 

Before that, just a question: are you using any other SDK / plugin in your app, or otherwise do you have any date extensions in your code? 

 

I want to set up a testing up with as similar a setup as you have as possible to see if I can reproduce locally, which would be immensely helpful

Userlevel 3
Badge +8

I do appreciate the generous offer, I have one file that has all your API, so your world is contained.  Let us do that, I am ready…

Userlevel 3
Badge +5

Yeah, it would be easier if this were widespread, but unfortunately we haven’t had anyone else report something of this severity. 


Could be conflicting extensions, could be a race condition or something off about your integration with us. 

Have you shared code samples with us? That’s why I suggested a little pairing session. There might be something innocuous that one of our engineers could figure out. We don’t generally offer this, but in this case we’ve pretty much exhausted other investigation methods.

Userlevel 3
Badge +8

Thanks @Jacob Eiting, I am happy to put as much time in this issue and code to highlight what is going on.  I like your company echo system but it is now something that is killing my app reputation.  The frequency of restore can be every day. I use my app and it happens to me every week or so, no pattern I can report, some users reports daily.  The main issues are:-

  1. Customer info comes nil from time to time, random.
  2. some users get errors and I attached the error details along this thread. 

Happy to put any code for future release to help find the root issue.  It started to happen after iOS 15 for sure, before that, customer info was always ready and valid. 

Userlevel 3
Badge +5

Hey @imougy,

 

Firstly, thanks for being so helpful on this issue. Software is hard and it’s always nice when we’re working with folks share so much detail. 

 

The issue was brought to my attention today as part of a broader push to improve the tools we have for helping debug tricky issues like this. 

 

> users must restore purchases from time to time

Not sure how frequent this is, but I think it’s a pretty normal ticket and not always indicative of an issue. If a customer switches devices for example, or changes App Store accounts. Not saying there isn’t something further going on, but even a perfect implementation will generate some background noise level of these. 

 

The error log is still abnormal and we’re working the problem. Sorry about the whole thing. At this stage, we might be able to investigate further if we could pair debug with you. Would you be open to that if we set up some time with an engineer?

Userlevel 3
Badge +8

@Winston Du @taquitos @cody just to let you know that the issue still happens, users must restore purchases from time to time.  For those users who can’t restore, when they change region to USA l, restore starts to work.
Please see latest log from a user in my previous message. 
my users who don’t know what is going on are leaving reviews that I am asking for purchases that they already paid for, nasty reviews and I can’t blame them.  Sad this issue is going on for months now, I am sadly thinking of using another in-app SDK.
 

Userlevel 3
Badge +8

I installed Beta.8 and played with it on my device.  After many launches on my device, I get an instance where customerInfo has no entitlements and no error (I do have some entitlements).  After the app quit and relaunch, the entitlements came fine.  I am releasing the app anyway, pending Apple approval now.

One of the users told me that Restore Purchases didn’t work for him, attached is his error, I told him to change to region to USA, his region was some where in Netherland, after he changed the region, the Restore worked fine.

Will keep you updated...

@Winston Du  and @imougy I’ve made a tag and the release is happening. Should be done within the next 30 minutes 🎉
https://github.com/RevenueCat/purchases-ios/releases/tag/4.0.0-beta.8

If you’re using SPM, you should be good to go now 😄 Thank you @Winston Du for the assist!

Userlevel 3
Badge +8

@Winston Du in my app, I myself get affected from time to time, I get empty customerInfo and need to restore purchases.  I have US local.  The randomness of the issue is a puzzle to me, unless some dates are parsed and others are not!

Anyway, I am eagerly awaiting any fix to test.

@Winston Du  Thanks for the follow up and I hope I can report good news when I get this change. @taquitos please keep me in touch so I can get this change.

@taquitos ,

I didn’t even realize that change was not in beta-7! So ignore my previous post. Because it turns out the rewrite wasn’t the issue, it was actually a solution!
 

@imougy 

The original issue is resolved by using the recent change to use the `ISO8601DateFormatter`. https://github.com/RevenueCat/purchases-ios/issues/1096#issuecomment-997470529

It seems the original `iso8601dateformatter` code had subtle buggy issues for users with unconventional calendar or date/time settings for non-US locales. After we used a version of the SDK with the rewritten DateFormatter, our issues were resolved for our users.

Oh wow! Yeah, maybe that could do it. We recently rewrote our iso8601DateFormatter to use the newer `ISO8601DateFormatter`, but haven’t released a beta with it include: https://github.com/RevenueCat/purchases-ios/blob/main/Purchases/FoundationExtensions/DateFormatter%2BExtensions.swift

We’re still finishing up the last bit of StoreKit2 additions and then we’ll release another Beta. Are you able to test out this theory building from `main`?

@taquitos ,

 

After taking a look at our code, we noticed we are using the Datadog SDK, which has a similar extension on ISO8601Formatter signature as the RevenueCat SDK (both of them have the class conform to a protocol of the same name)  (https://github.com/DataDog/dd-sdk-ios/blob/9cdb8fe7615949554e8a6af2ddbe2857050fed35/Sources/Datadog/Core/Utils/DateFormatting.swift)

Do you think this could cause any issues?

Reply