Potential fix for flaky test #5395
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The test
testCallToGetCustomerInfoWithPendingTransactionsPostsReceiptOnlyOnce()
is randomly failing. This PR attempts to fix it.More details
The test is sometimes failing with this error:
The error shows that the entitlement is not active while it should be active. But if you notice the dates in the log,
latestPurchaseDate
is exactly the same asexpirationDate
. This makes me think that, if the test runs fast enough, the linescan produce two transactions with the same
purchase_date
(and the first one having also the sameexpires_date
aspurchase_date
). This has just happened to me when running the test locally:I suspect that, because both transactions have the same
purchase_date
, the first one may be randomly picked between the two. In this case, the test then would fail because that transaction (with sameexpires_date
aspurchase_date
) doesn't grant the entitlement anymore.This is confirmed by the test error message having
periodType=PeriodType(rawValue: 1)
, which is thePeriodType.intro
enum case and it showing thatlatestPurchaseDate
==expirationDate
. Only the first transaction is the intro offer one.My reasoning is that by adding 1 second delay between the two transactions will make sure that the two transactions always have a different
purchase_date
, so that the second transaction is always the one being picked as the latest one