Skip to content

Continue running the stress tester after an error is encountered #146

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

Merged
merged 6 commits into from
Jun 11, 2021

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented May 3, 2021

The stress tester runs stable enough on the test suite now that a failure isn’t likely to cause a whole bunch of following failures.

Instead, continue running after a failures is encountered to get a more complete picture of the SourceKit issues in the source compatibility suite. The current behaviour of uncovering new issues after XFailed issues are fixed is annoying.

@ahoppen
Copy link
Member Author

ahoppen commented May 3, 2021

Let’s see what kind of results we get out of this. Taking too long to run locally…

@swift-ci Please test

@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch from 2fac180 to 7477138 Compare May 27, 2021 21:14
@ahoppen ahoppen changed the title Don't stop scheduling new operations when a failures is encountered [WIP] Don't stop scheduling new operations when a failures is encountered May 27, 2021
@ahoppen ahoppen marked this pull request as ready for review May 27, 2021 21:15
@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch 2 times, most recently from 7ce71f3 to b819dc4 Compare May 28, 2021 19:17
ahoppen added 3 commits June 10, 2021 23:34
`SourceKitDocument` should have reference semantics, because if we pass it around, we want all instances to refer to the same object.
@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch from 0d20196 to 220e520 Compare June 11, 2021 05:58
@ahoppen ahoppen changed the title [WIP] Don't stop scheduling new operations when a failures is encountered Don't stop scheduling new operations when a failures is encountered Jun 11, 2021
@ahoppen ahoppen changed the title Don't stop scheduling new operations when a failures is encountered Continue running the stress tester after an error es encountered Jun 11, 2021
@ahoppen ahoppen requested a review from bnbarham June 11, 2021 06:09
@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch 2 times, most recently from d916129 to 2c9ac71 Compare June 11, 2021 07:14
Copy link
Contributor

@bnbarham bnbarham left a comment

Choose a reason for hiding this comment

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

Just some small cleanups, but otherwise LGTM (as much as crash recovery can look good 😆)

let (actions, priorActions) = computeActions(from: tree)

var errors: [Error] = []
Copy link
Contributor

Choose a reason for hiding this comment

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

This doesn't really matter, but I'd prefer the ones outside the loop to just return [error] and then only use this for the loop. Or use errors in the last do/catch as well.

Comment on lines +137 to +141
// We can control whether to stop scheduling new operations here. As long
// as we return `true`, the stress tester continues to schedule new
// test operations. To stop at the first failure, return
// `operation.status.isPassed`.
return true
Copy link
Contributor

Choose a reason for hiding this comment

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

Could change FailFastOperationQueue to something like OperationQueue(failFast:). Just seems kind of weird to use a "failing fast" queue and then not fail fast 😆.

Copy link
Member Author

Choose a reason for hiding this comment

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

I renamed it to StressTesterOperationQueue but left the API the same.


private var state: State = .running {
didSet {
if #available(macOS 10.12, *) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this still needed (since it is set in the package)?

Comment on lines 242 to 244
if isNull { return false }
guard let notification = value.getOptional(.key_Notification)?.getUID()
else { return false }
Copy link
Contributor

Choose a reason for hiding this comment

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

Could factor this out into notificationType but there's only two, so not too bad right now.

The stress tester runs stable enough on the test suite now that a failure isn’t likely to cause a whole bunch of following failures.

Instead, continue running after a failures is encountered to get a more complete picture of the SourceKit issues in the source compatibility suite. The current behaviour of uncovering new issues after XFailed issues are fixed is annoying.
@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch from 2c9ac71 to aa7bb02 Compare June 11, 2021 07:35
@ahoppen ahoppen changed the title Continue running the stress tester after an error es encountered Continue running the stress tester after an error is encountered Jun 11, 2021
@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch from 4365f15 to de7fd46 Compare June 11, 2021 14:55
ahoppen added 2 commits June 11, 2021 19:23
We are no longer using this queue to fail fast, so the name seems misleading.
Shutdown an re-initialize would (sometimes?) give us back the previous XPC connection. The crash request is working even if SourceKit is busy fulfilling other requests and is guaranteed to spawn a new process.
@ahoppen ahoppen force-pushed the pr/dont-stop-on-error branch from de7fd46 to 3d6a913 Compare June 11, 2021 17:23
@ahoppen
Copy link
Member Author

ahoppen commented Jun 11, 2021

@swift-ci Please test

@swiftlang swiftlang deleted a comment from swift-ci Jun 11, 2021
@swiftlang swiftlang deleted a comment from swift-ci Jun 11, 2021
@swiftlang swiftlang deleted a comment from swift-ci Jun 11, 2021
@ahoppen ahoppen merged commit f097653 into swiftlang:main Jun 11, 2021
@ahoppen ahoppen deleted the pr/dont-stop-on-error branch November 18, 2021 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants