Skip to content
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

Enable Core Data concurrency debug option in UI tests #20395

Merged

Conversation

crazytonyli
Copy link
Contributor

The app crashes during UI tests when a Core Data concurrency issue occurs.

A Core Data concurrency issue is typically where a managed object is accessed outside of the context (or the queue managed by the context). Currently there are still many such issues in the app, post editing being the most impacted one, which is why the new
crashOnCoreDataConcurrencyIssue option is disabled in EditorGutenbergTests.

But, I think it's still valuable to ensure that those areas that don't have any Core Data concurrency issues to be maintained. And we should expose the new issue if one does occur. Doing that in UI tests is one easy way I can think of, which doesn't have a "blocking" factor—we can always disable the check for specific test(s).

Regression Notes

N/A

PR submission checklist:

  • I have completed the Regression Notes.
  • I have considered adding unit tests for my changes.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@crazytonyli crazytonyli added the Core Data Issues related to Core Data label Mar 24, 2023
@crazytonyli crazytonyli added this to the 22.1 milestone Mar 24, 2023
@crazytonyli crazytonyli requested a review from mokagio March 24, 2023 00:22
@crazytonyli crazytonyli self-assigned this Mar 24, 2023
@crazytonyli crazytonyli requested a review from a team as a code owner March 24, 2023 00:22
@wpmobilebot
Copy link
Contributor

wpmobilebot commented Mar 24, 2023

WordPress Alpha📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
App NameWordPress Alpha WordPress Alpha
ConfigurationRelease-Alpha
Build Numberpr20395-46f6655
Version22.0
Bundle IDorg.wordpress.alpha
Commit46f6655
App Center BuildWPiOS - One-Offs #5387
Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

@wpmobilebot
Copy link
Contributor

wpmobilebot commented Mar 24, 2023

Jetpack Alpha📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
App NameJetpack Alpha Jetpack Alpha
ConfigurationRelease-Alpha
Build Numberpr20395-46f6655
Version22.0
Bundle IDcom.jetpack.alpha
Commit46f6655
App Center Buildjetpack-installable-builds #4415
Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

@crazytonyli crazytonyli force-pushed the enable-core-data-concurrency-debug-option-in-ui-tests branch from 0074f2b to 240cd08 Compare March 24, 2023 01:53
Copy link
Contributor

@mokagio mokagio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The UI tests on iPhone had 26 failures (waiting for #20378 to have better reporting on flakiness). I wonder how many of those were due to Core Data issues 🤔

If there are many, I'd worry they would introduce too much noise in the report—Unless, that is, we committed to fix those issues ASAP.

super.setUp()

// In UI tests it is usually best to stop immediately when a failure occurs.
continueAfterFailure = false

app.launchArguments = ["-wpcom-api-base-url", WireMock.URL().absoluteString, "-no-animations", "-ui-testing"]

if crashOnCoreDataConcurrencyIssues {
app.launchArguments.append(contentsOf: ["-com.apple.CoreData.ConcurrencyDebug", "1"])
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a subset of the tests use setUpTestSuite, which would result in this argument being applied inconsistently.

Have you considered using the test plan to set it and use this method to opt-out only?

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. I hadn't thought about it, but I'll give it a go.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a subset of the tests use setUpTestSuite

The idea is only turn the debug option on for UI tests, which all calls this funciton, I think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[UI tests] all calls this funciton, I think?

Oh, that is correct. I don't know why I got the impression only some of them called setUpTestSuite 🤔 But I checked each test and they all do.

Apologies.

@crazytonyli
Copy link
Contributor Author

The UI tests on iPhone had 26 failures

Sorry, I should've mentioned in the PR description. All those failures should be addressed by #20394. I'll wait for that PR to be merged to re-run all the UI tests in this PR.

[...] have better reporting on flakiness

I don't think this change would cause flaky tests. I can later try re-run UI tests a few times to be sure.

@mokagio
Copy link
Contributor

mokagio commented Mar 28, 2023

@crazytonyli I see #20394 is not in this branch via 66b4efc. However, we still have more UI tests failures than other branches 🤔

@crazytonyli
Copy link
Contributor Author

I think the UI tests failed because they caught a known Core Data concurrency issue which should be fixed by #20413. Unfortunately, the CI job doesn't tell us the failure reason. The result bundle just says "timeout" because the app crashed. So, it would be good to attach a crash report to the result bundle if that's possible.

@crazytonyli crazytonyli force-pushed the enable-core-data-concurrency-debug-option-in-ui-tests branch from 66b4efc to 87892b5 Compare March 30, 2023 08:18
Copy link
Contributor

@mokagio mokagio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like all the tests failures we saw initially have been addressed by the PRs, as expected.

:shipit:

@crazytonyli
Copy link
Contributor Author

I can later try re-run UI tests a few times to be sure.

Buildkite doesn't allow retrying a successful step. I think I'll have to amend the git history to re-build, which is what I'm going to do, for a few times, to be sure that this change won't cause UI test becoming flaky.

@crazytonyli crazytonyli force-pushed the enable-core-data-concurrency-debug-option-in-ui-tests branch from 87892b5 to cd00c76 Compare April 2, 2023 21:34
The app crashes during UI tests when a Core Data concurrency issue occurs.

A Core Data concurrency issue is typically where a managed object is
accessed outside of the context (or the queue managed by the context).
Currently there are still many such issues in the app, post editing
being the most impacted one, which is why the new
`crashOnCoreDataConcurrencyIssue` option is disabled in `EditorGutenbergTests`.

But, I think it's still valuable to ensure that those areas that don't
have any Core Data concurrency issues to be maintained. And we should
expose the new issue if one does occur. Doing that in UI tests is one
easy way I can think of, which doesn't have a "blocking" factor—we can
always disable the check for specific test(s).
@crazytonyli crazytonyli force-pushed the enable-core-data-concurrency-debug-option-in-ui-tests branch from cd00c76 to 46f6655 Compare April 2, 2023 23:50
@peril-wordpress-mobile
Copy link

Warnings
⚠️ This PR is assigned to a milestone which is closing in less than 4 days Please, make sure to get it merged by then or assign it to a later expiring milestone

Generated by 🚫 dangerJS

@mokagio
Copy link
Contributor

mokagio commented Apr 3, 2023

Buildkite doesn't allow retrying a successful step. I think I'll have to amend the git history to re-build, which is what I'm going to do, for a few times, to be sure that this change won't cause UI test becoming flaky.

I opened #20461 to run the UI tests step 6 times, which should increase our confidence.

I'm also going to bump this milestone to 22.2 as I'm about to code freeze 22.1 and this is not a user facing PR so it doesn't matter whether it lands in 22.1 now or on trunk after the code freeze.

@mokagio mokagio modified the milestones: 22.1, 22.2 Apr 3, 2023
@crazytonyli
Copy link
Contributor Author

The CI jobs have been passing three times in a row, which I'll take as a confirmation that this PR doesn't cause flaky UI tests and merge this PR.

Screenshot 2023-04-03 at 1 00 37 PM

@crazytonyli crazytonyli merged commit f316bf4 into trunk Apr 3, 2023
@crazytonyli crazytonyli deleted the enable-core-data-concurrency-debug-option-in-ui-tests branch April 3, 2023 01:02
@mokagio
Copy link
Contributor

mokagio commented Apr 3, 2023

@crazytonyli race condition 😄

image

Anyway, good choice. I should have checked to see if theres was something running in CI before going ahead and starting my experiment. I'll cancel it, then.

@mokagio mokagio removed this from the 22.2 milestone Apr 3, 2023
@mokagio mokagio added this to the 22.1 milestone Apr 3, 2023
@crazytonyli
Copy link
Contributor Author

@mokagio Ops, sorry. That's a way smarter approach than my force-push 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Data Issues related to Core Data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants