@Kev this is a bit related to this post, and “anonymous purchases” in general. I’m not sure if it’s a 100% avoidable scenario since Apple / Google only require a signed in Apple / Google account and there’s cases in where a transaction could go through and an App User ID isn’t set - which is why the RCAnonymousIDs exist in the first place.
In general, if you’re able to set the customer facing subscription status from the SDK directly, then have more asynchronous processes to ensure eventual consistency of server-side subscription status your customers are at least immune to these cases where things get out of sync. If realtime server-side subscription status is a requirement, then having a way for the customer to restore purchases and manually trigger a re-sync would be my recommendation.
You could have a “Restore Purchases” button in your app that required the customer be signed in (if that’s how your app is supposed to work) by checking the `isAnonymous` property on `PurchaserInfo`. Then if that customer triggers a restore, you know you’ll get a `TRANSFER` webhook soon if that customer was accidentally logged in with a different account or something.
I’m going to share both of these threads with our product team as well for feedback!