Question

Getting an expired entitlement, but also ITEM_ALREADY_OWNED when trying to purchase

  • 13 October 2022
  • 6 replies
  • 104 views
G
Badge +3

I'm testing on a physical android device, and have behavior I can not explain:

  • I purchase a subscription
  • The subscription is automatically stopped after 5 minutes
  • I then try to purchase it again but I get errorcode ITEM_ALREADY_OWNED

I can close the app and try again, but still get the error code

If I refresh with the login method, the problem is still present, I am no longer entitled

Is there some kind of server - timing issue going on here?

After some (?) time I am able to purchase a subscription again, unsure when things are matching up again.


Or maybe there is there a problem with me checking the validity?
 

C# code:
ExpirationDate = ToDateTime(entitlement.ExpirationDate);

private DateTime ToDateTime(Java.Util.Date date)
        {
            var baseValue = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
            return baseValue.AddMilliseconds(date.Time);
        }

6 replies

G
Badge +3

I have done some additional testing.

I had a situation where the login method said the subscription was expired, and then a RC web-api call said it was not expired.
 

I also had the situation where the login method said the subscription was expired, and then a few seconds later, said it was not expired.
 

It almost seemed like the auto-renewing function of android is not spot on (not extending the subscription directly, but maybe after a minute or two of being unsubscribed). I don't think this is the case though.


What I think is a more plausible reason is that it's a RC caching issue.
When I do the login method, it still considers its cache (sub has expired) valid and returns it, but it is actually stale info (sub is renewed on backend). Then, in a few minutes time the cache is considered stale and refreshed from the backend and then sees the subscription has been extended by another 5 minutes or so and returns the subscription as active.

If this is the case it would be a good idea to invalidate the RC cache at least once when the subscription expire date has passed, getting a “fresh” status for auto-renewing subscriptions.

G
Badge +3

Hmm I tried invalidating the cache after the cached ExpirationDate had passed, but still got an expired subscription with the login method.

The 5 minute renew schedule of the testing environment might not be representative of the actual renewing process. 
I'm gonna assume this is some server side timing issue unless I get a reaction from someone that helps me along.
 

G
Badge +3

I just noticed the situation where both the backend (WebApi) and the in-app library gave back an expired subscription one minute, and a renewed one the next.

Miguel Carranza
Rank
Userlevel 2
Badge +6

Hi Guido,

 

It seems you are calling the login method multiple times in your application. You should only be calling it once, otherwise the app user id will reset, creating effectively a new user in RevenueCat.

Miguel
G
Badge +3

Hi Miguel, thank you for responding.
Does this apply even if I am logging in with my own installation Id that is the same every time?

The reason I was doing this was because the wrapper I'm using did not provide me with a convenience method to call getCustomerInfo, and the login method returns the same object.
 

Miguel Carranza
Rank
Userlevel 2
Badge +6

Mhhh I definitely would not call logIn multiple times, unless you have a reason to log out / log a new user in. Having said that, what you might be seeing could be due to the accelerated renewal rate in sandbox (5 minutes). This should not happen in production, since duration is much longer. I’d suggest trying with a yearly subscription (which takes 30 min to renew instead of 5 minutes)

Miguel

Reply


Terms & ConditionsCookie settings