-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StoreKitIntegrationTests
: removed incorrect waitUntilCustomerInfoIsUpdated
and fixed race condition
#1492
Conversation
199de6c
to
ee63201
Compare
StoreKitIntegrationTests
: removed incorrect waitUntilCustomerInfoIsUpdated
StoreKitIntegrationTests
: removed incorrect waitUntilCustomerInfoIsUpdated
and improved all assertions
Still looking into the flaky integration test failures. |
StoreKitIntegrationTests
: removed incorrect waitUntilCustomerInfoIsUpdated
and improved all assertionsStoreKitIntegrationTests
: removed incorrect waitUntilCustomerInfoIsUpdated
and fixed race condition
fc15fbb
to
b14803a
Compare
) async throws -> PurchaseResultData { | ||
let data = try await Purchases.shared.purchase(package: self.monthlyPackage) | ||
|
||
try self.verifyEntitlementWentThrough(data.customerInfo, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All purchases through this method now verify the entitlement for good measure (instead of most tests doing that repeatedly).
caf0340
to
49e9440
Compare
49e9440
to
bec70ab
Compare
It's interesting, looking at the trend of failures in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was convinced I had approved already!! 😅
Turns out we had already solved this race condition in #1492 that lead to flaky failures, but it was only in `BaseStoreKitIntegrationTests`. This moves it up to `BaseBackendIntegrationTests` so that `SubscriberAttributesManagerIntegrationTests` can use it too. Fixes https://app.circleci.com/pipelines/github/RevenueCat/purchases-ios/10501/workflows/cb6dbf22-cda8-4c41-875b-04b489992631/jobs/61135
…2381) Turns out we had already solved this race condition in #1492 that lead to flaky failures, but it was only in `BaseStoreKitIntegrationTests`. This moves it up to `BaseBackendIntegrationTests` so that `SubscriberAttributesManagerIntegrationTests` can use it too. Fixes https://app.circleci.com/pipelines/github/RevenueCat/purchases-ios/10501/workflows/cb6dbf22-cda8-4c41-875b-04b489992631/jobs/61135
This is probably a leftover from before integration tests got changed to async.
Purchases
initialization can fetch an updatedCustomerInfo
, so assuming this will be 1 is a race condition waiting to happen, because there are potentially multiple customer info requests happening.Also, SDK initialization begins with an initial request to offerings, which results in a get-create of the initial anonymous user. To avoid race conditions with when this request finishes and make all tests deterministic, integration tests now wait for the initial get offerings to finish
Changes:
waitUntilCustomerInfoIsUpdated
verifyEntitlementWentThrough
now callsverifyEntitlementWentThrough
to verify theCustomerInfo
has the correct entitlementPurchasesDelegate.customerInfo
in all tests, which could lead to race conditions