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

[Test Only] Add a sleep to 'testInputModifiedDuringSingleJobBuild' to accomodate filesystems with insufficient timestamp precision #1810

Merged
merged 1 commit into from
Feb 18, 2025

Conversation

artemcm
Copy link
Contributor

@artemcm artemcm commented Feb 14, 2025

No description provided.

@artemcm
Copy link
Contributor Author

artemcm commented Feb 14, 2025

@swift-ci test

@@ -356,6 +356,10 @@ final class JobExecutorTests: XCTestCase {
XCTAssertEqual(jobs.count, 1)
XCTAssertTrue(jobs[0].requiresInPlaceExecution)

// Sleep for 1s to allow for quiescing mtimes on filesystems with
// insufficient timestamp precision.
Thread.sleep(forTimeInterval: 1)
Copy link

Choose a reason for hiding this comment

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

Issue (possibly-blocking): I cringe when I see "sleep" in a test as there will always be room for flakiness here.

Instead of relying of sleep, is there a more deterministic wait of determining when we are ready to proceed?

With sleep:

  • we may not wait long enough, causing for intermittent failure
  • the condition for waiting is met "quickly", causing the test to wait for no reason

I understand this is a quick solution, but it may be the cause of a flaky test, which is not ideal to have.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Flakiness in this test after this change would mean a serious issue and any test failure would require investigation.

The test is designed to detect a change to a file being done in a specific interval of time, and to do so we need to ensure there actually is an interval of time. On some platforms, code execution between file creation and modification is a sufficient interval of time per filesystem timestamp granularity. On others, it is not so we must establish a time interval, as per other incremental compilation tests in this suite as well. It is true that the condition is met more quickly than the sleep interval, however it is also not a threshold that would meaningfully affect the parallel test suite runtime. The threshold of sleep here is picked very conservatively to ensure that "we may not wait long enough, causing for intermittent failure" does not happen. Meaning that "there will always be room for flakiness here" and "it may be the cause of a flaky test" is not true.

@artemcm
Copy link
Contributor Author

artemcm commented Feb 17, 2025

@swift-ci test Linux platform

@cachemeifyoucan
Copy link
Contributor

I think the fix is fine for using sleep, can we also update the check so it doesn't call driver.run() but just call job.verifyInputsNotModified() directly to avoid exec?

… accomodate filesystems with insufficient timestamp precision
@artemcm artemcm force-pushed the NeedSleepToGetItRight branch from ddd8d84 to 2169ff5 Compare February 17, 2025 22:34
@artemcm
Copy link
Contributor Author

artemcm commented Feb 17, 2025

@swift-ci test

@artemcm
Copy link
Contributor Author

artemcm commented Feb 17, 2025

@swift-ci test Windows platform

@artemcm
Copy link
Contributor Author

artemcm commented Feb 17, 2025

I think the fix is fine for using sleep, can we also update the check so it doesn't call driver.run() but just call job.verifyInputsNotModified() directly to avoid exec?

Great idea. Done.

@artemcm artemcm enabled auto-merge (rebase) February 17, 2025 22:35
@artemcm
Copy link
Contributor Author

artemcm commented Feb 18, 2025

@swift-ci test Windows platform

@artemcm artemcm merged commit 5f5afac into swiftlang:main Feb 18, 2025
3 checks passed
@artemcm artemcm deleted the NeedSleepToGetItRight branch February 18, 2025 17:02
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.

3 participants