Question

What should we do to avoid having more than 50 aliases?

  • 1 November 2023
  • 4 replies
  • 110 views
Fewlaps
Badge +5

Hello there!

We’ve been struggling with a user that has and loses its entitlements from time to time, with no reason. To fix it, we built our RevenueCat integration from scratch, because we upgraded different major versions too easily… and well, it sounded we were logging in too much, restoring purchases too much, etc.

So during the debugging we arrived to this error:

There was an unknown backend error. Error creating subscriber alias. Alias limit reached. (7255)

In this GitHub issue in the iOS SDK we saw that the root problem is that you changed something in your backend that made a user not have more than 50 aliases.

I don’t want to discuss if it’s a good decision or not, because maybe it is, but what should we do in case someone logs in, restores purchases, logs out, restores purchases, logs in, restores purchases, logs out, restore purchases… a lot of times? Eventually that user will create 50 aliases, but that’s a fair behavior, right?

Or just a person that downloads the app 25 times, restores purchases as anonymous, and then logs in. It’s also 50 aliases, right…?

How should we handle that case from our side, programmatically? Should we delete the anonymous users before logging in or something like that?

Thanks a lot :·)

Quit smoking with QuitNow: https://quitnow.app

4 replies

H
Rank
Userlevel 4
Badge +8

Hi, right now our alias limit is currently 50. It is common to see this in sandbox testing, and to resolve this you would want to delete the app user id in RevenueCat and make a new one, which will get rid of their aliases. If you are seeing this happen in production, this may be a result of this user deleting and re-installing the app, or if the user is logging in and out of their account, which would assign them a new anonymous user id. Then they would call restore purchases which would merge the two anonymous ids.
 
Having many aliases in production can be a sign of either a bug in your app that is creating new app user ids and aliasing them, or it could be a sign of account sharing. To prevent such cases, we have decided to be more strict with our alias limit.

 

In cases like this, I recommend deleting the user and then when this user logs in, they can restore purchases and will no longer have any aliases. Alternatively, you could look into changing your restore behavior to be more strict such as ‘transfer if there are no active subscriptions’ or ‘keep with original app user id’: https://www.revenuecat.com/docs/restoring-purchases#transfer-if-there-are-no-active-subscriptions. Right now you might have your restore behavior as ‘share between app user ids’ which is meant to create many aliases: https://www.revenuecat.com/docs/restoring-purchases#share-between-app-user-ids-legacy

Fewlaps
Badge +5

Yes, but logging out and logging in again can also be legitimate use.

We’re having this issue on production, because some people uninstall our app and install it again several times, or they log in and out from the app a lot of times, or they just do that but in addition, they have more than one device. They are all legit use cases. I get your concerns, but RevenueCat shouldn’t stop working because of this behavior. The users are not doing anything bad, and that’s not fair to them.

What can we do from our side? Is there any way we can do something about it programmatically?

Please, understand that the problem affects people who paid for the service. We as RevenueCat customers, but also our customers that subscribed to our services. If it only affected free users I wouldn’t care that much, actually, but it’s affecting the ones who deserve great user support.

Quit smoking with QuitNow: https://quitnow.app
H
Rank
Userlevel 4
Badge +8

A quickfix for this would be to delete the user that is throwing this error, and then when the user logs in they can restore purchases and will no longer have any aliases so this count will be reset.

 

A longtime solution to this would be to create an authentication system and login users with a custom id so that all those aliases aren’t created and the user can just share purchases between their devices via the one id.

 

I will pass along your feedback to the team regarding this and will also check with the team on this to see if there are additional workarounds and I will let you know.

Fewlaps
Badge +5

Oh, but we have an authentication system, and they can share the purchases with that “one ID”. I suspect the problem is when they log out. Then they are given a new anonymous user ID, and when they log in again, I understand that the anonymous user ID is then linked to our “one ID”.

Look, what we see in Crashlytics is something like this:

The root error so people can’t restore purchases

Let’s say a user with “one ID” `QN:ABC` logs out. After logging out, we restore his purchases because, as that purchase is made with his phone, we want to still let the user use his entitlements. If not, the entitlements are linked to `QN:ABC` and now the new anonymous user.

I understand that at that moment, as that user could have many aliases, the purchase can’t be linked to the new anonymous alias. Is that right? So they don’t receive the entitlement. Or maybe the opposite, the entitlement is linked to an anonymous user with that much aliases, that when the user logs in, the purchase can’t be linked to the “one ID” user because it also have too many aliases. Is that right?

In that last case, I could catch this Exception, and request the backend to call your API to delete that “one ID” from your systems, so eventually, the magic will work again. But will that delete all the related aliases, or only the “one ID”? I understand I should call `https://www.revenuecat.com/reference/delete-subscriber`, and then, when I have your 200, restore the purchases again, and it will work flawlessly?

By the way, I’m very focused on fixing this bug or helping you in addressing it. Don’t hesitate to request me to make a call and share our use of your SDK.

Quit smoking with QuitNow: https://quitnow.app

Reply


Terms & ConditionsCookie settings