Enable Core Data concurrency debug option in UI tests - #20395
Conversation
|
| App Name | ||
| Configuration | Release-Alpha | |
| Build Number | pr20395-46f6655 | |
| Version | 22.0 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 46f6655 | |
| App Center Build | WPiOS - One-Offs #5387 |
|
| App Name | ||
| Configuration | Release-Alpha | |
| Build Number | pr20395-46f6655 | |
| Version | 22.0 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 46f6655 | |
| App Center Build | jetpack-installable-builds #4415 |
0074f2b to
240cd08
Compare
mokagio
left a comment
There was a problem hiding this comment.
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.
|
|
||
| if crashOnCoreDataConcurrencyIssues { | ||
| app.launchArguments.append(contentsOf: ["-com.apple.CoreData.ConcurrencyDebug", "1"]) | ||
| } |
There was a problem hiding this comment.
Good suggestion. I hadn't thought about it, but I'll give it a go.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
[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.
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.
I don't think this change would cause flaky tests. I can later try re-run UI tests a few times to be sure. |
|
@crazytonyli I see #20394 is not in this branch via |
|
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. |
66b4efc to
87892b5
Compare
mokagio
left a comment
There was a problem hiding this comment.
Looks like all the tests failures we saw initially have been addressed by the PRs, as expected.
![]()
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. |
87892b5 to
cd00c76
Compare
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).
cd00c76 to
46f6655
Compare
Generated by 🚫 dangerJS |
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 |
|
@crazytonyli race condition 😄 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 Ops, sorry. That's a way smarter approach than my force-push 👍 |



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
crashOnCoreDataConcurrencyIssueoption is disabled inEditorGutenbergTests.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:
RELEASE-NOTES.txtif necessary.