In SequencedSkyframeExecutorTest#testThreeSharedActionsRacing, make sure action C has started before interrupting the main thread.
If the main thread really dallies, it might not enqueue C before the build is interrupted, causing a deadlock as action A waits for C's signal before finishing.
I verified in a debugger that without this fix, I could cause a deadlock like the one in the linked bug. However, the deadlock didn't repro for me in 2k runs without this fix, so I can't be totally positive that this fixes the issue.
PiperOrigin-RevId: 302211501
diff --git a/src/test/java/com/google/devtools/build/lib/skyframe/SequencedSkyframeExecutorTest.java b/src/test/java/com/google/devtools/build/lib/skyframe/SequencedSkyframeExecutorTest.java
index 2866ae1..69f5365 100644
--- a/src/test/java/com/google/devtools/build/lib/skyframe/SequencedSkyframeExecutorTest.java
+++ b/src/test/java/com/google/devtools/build/lib/skyframe/SequencedSkyframeExecutorTest.java
@@ -848,7 +848,7 @@
// long enough can lead to a flaky pass.
Thread mainThread = Thread.currentThread();
-
+ CountDownLatch cStarted = new CountDownLatch(1);
skyframeExecutor
.getEvaluatorForTesting()
.injectGraphTransformerForTesting(
@@ -860,6 +860,7 @@
TrackingAwaiter.INSTANCE.awaitLatchAndTrackExceptions(
actionAStartedSoOthersCanProceed, "primary didn't start");
if (key.equals(lcC)) {
+ cStarted.countDown();
// Wait until interrupted.
try {
Thread.sleep(TestUtils.WAIT_TIMEOUT_MILLISECONDS);
@@ -879,6 +880,7 @@
&& key.equals(lcB)
&& order == NotifyingHelper.Order.BEFORE
&& context != null) {
+ TrackingAwaiter.INSTANCE.awaitLatchAndTrackExceptions(cStarted, "c missing");
// B thread has finished its run. Interrupt build!
mainThread.interrupt();
} else if (type == EventType.ADD_REVERSE_DEP
