Skip to main content

Within a local Xcode testing environment we sometimes run in to the following error (which is received from RevenueCat):

Error Domain=RCBackendErrorDomain Code=7638 "There is another request in flight trying to perform the same action."

This is the error that we receive back when we try and make a purchase (within the following code block):

    func purchase(package: Package, completion: @escaping (InAppPurchaseResult) -> Void) {
purchasePackage(package) { _, purchaserInfo, error, userCanceled in
if userCanceled {
completion(.userCancelled)
} else if let error = error {
completion(.failure(error))
print(error)
print(error.localizedDescription)
} else if purchaserInfo?.entitlements.all["unlocked"]?.isActive == true {
completion(.success)
} else {
// According to RevenueCat doc it should never happen
}
}
}

Even though we receive the error, the purchase goes through successfully.

 

The more testing we do, the more we feel that this may be a result of errors in a local Sandbox testing environment. But it would be great to hear if anyone has faced a similar issue and why it exists.

 

We don’t know if this exist in production code (as we haven’t released it yet)!

 

Thanks so much 😄

We are seeing this in our backend when we call RevenueCat API to know the state of a user subscription.


We are seeing this in our backend when we call RevenueCat API to know the state of a user subscription.

Same here


We also see this error 

Anyone able to solve this problem ?

>"rc_successfullySynced": 1, "NSUnderlyingError": Error Domain=RCBackendErrorDomain Code=7638 "There is another request in flight trying to perform the same action." UserInfo={NSLocalizedDescription=There is another request in flight trying to perform the same action.}, "finishable": 1, "readable_error_code": UNKNOWN, "NSLocalizedDescription": Unknown error.]
 


Hello! Sorry for the late reply here, but I just wrote up a guide about this error: 

TLDR: You likely made multiple requests that are attempting to update the same resource in RevenueCat, so RevenueCat blocked them to prevent race conditions. Even a GET /subscribers call can result in updates on RevenueCat’s end - for example, to update the last seen date, refresh the receipt if it hasn’t been refreshed recently, etc. If you get this error it’s safe to retry the request a few seconds later. 

This might happen a little more frequently in sandbox due to the speed at which subscriptions renew. More updates are happening in a short time which may coincide with an API request that the SDK is making. Again, the solution here is to just retry the operation or function call a few seconds later, which should give RevenueCat time to finish processing any updates.


> the solution here is just to retry the operation

I didn’t get this error before upgrading from 3 to 4, now I see it all the time.

I don’t think a retry is necessary because the operation seemed to have succeeded. If I restart the app, the subscription works. So I think there’s a problem with what revenue cat is doing on the backend.


Hey @Todd Hoff ,

The recommendation to retry depends on what the operation is. The 429 doesn’t mean you always have to retry, it simply means that the request you made couldn’t be processed because a different request is already modifying the same resource, so you have to wait until that one finishes before you can make your request again. This can happen, for example, if you call POST /receipts while that user’s receipt is already being refreshed on our end, in which case we’ll return a 429 letting you know that we can’t accept the receipt you just sent. The SDK will retry the POST /receipts request on its own automatically. If you’re using our API directly it is up to you whether you want to retry or not.

If you’re getting 429 consistently after a specific action or pattern, then yes it does seem like something could be done differently there. I’m happy to look into that with you if you want.


All I’m doing is Purchases.shared.purchase(package: package), so that’s why I think it has to be on the revenuecat side.


It probably is on RevenueCat’s side, as calling purchasePackage will send a receipt to RevenueCat but if the user is already being updated at that time then the request could be denied with 429. This can be expected especially in sandbox because RevenueCat refreshes the user’s receipt very frequently so if you make a purchase at the time the receipt is being refreshed you may receive a 429. This is why retrying is ok and expected. In fact, the SDK will retry for you automatically (this is probably why quitting and launching the app is working for you.) But if you believe something unexpected is happening, please share the debug logs of this happening so I can investigate.


Here’s the error. If it just happens in the sandbox it’s ok, but I’m not sure how I would know that. I’m thinking of checking for the error and just assuming it worked.

2023-04-26 14:04:32.149997-0700 rehit037004:11678239] 6Purchases] - ERROR: 💰 Product purchase for 'mw_999_1y_2w0' failed with error: Error Domain=RevenueCat.ErrorCode Code=16 "There was an unknown backend error. There is another request in flight trying to perform the same action. (7638)" UserInfo={readable_error_code=UNKNOWN_BACKEND_ERROR, rc_backend_error_code=7638, source_file=RevenueCat/HTTPClient.swift:410, source_function=convertUnsuccessfulResponseToError(), NSLocalizedDescription=There was an unknown backend error. There is another request in flight trying to perform the same action. (7638), NSUnderlyingError=0x283b086c0 {Error Domain=RevenueCat.BackendErrorCode Code=-1 "There is another request in flight trying to perform the same action. (7638)" UserInfo={rc_backend_error_code=7638, NSLocalizedDescription=There is another request in flight trying to perform the same action. (7638)}}, rc_response_status_code=429}

2023-04-26 14:04:32.151728-0700 rehit-37004:11677495] :pay] PaywallView:Error: There was an unknown backend error. There is another request in flight trying to perform the same action. (7638)  code: 16

2023-04-26 14:04:32.687316-0700 rehit637004:11677495] <SKReceiptRefreshRequest: 0x2835fa780>: Finished refreshing receipt with error: Error Domain=ASDErrorDomain Code=603 "Request throttled" UserInfo={NSLocalizedFailureReason=Unified receipt is valid and current, NSLocalizedDescription=Request throttled, AMSServerErrorCode=0}


Hello, I wanted to mention that I have this problem too.  Sentry reports:

There was an unknown backend error. There is another request in flight trying to perform the same action. (7638)

It happens randomly when testing it in TestFlight using the React Native SDK.

```
const purchaseMade = await Purchases.purchasePackage(purchasePackage);

```

I am not sure what property to look for when identifying this exception, however, it doesn’t look like it should be retried especially since it would presumably require users to re-enter their credentials.


Reply