rangareddy commented on code in PR #19485: URL: https://github.com/apache/hudi/pull/19485#discussion_r3763778820
########## hudi-utilities/src/test/java/org/apache/hudi/utilities/deltastreamer/TestWaitTillCondition.java: ########## @@ -0,0 +1,111 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.hudi.utilities.deltastreamer; + +import org.junit.jupiter.api.Test; + +import java.util.concurrent.CompletableFuture; +import java.util.concurrent.Future; +import java.util.concurrent.atomic.AtomicInteger; + +import static org.junit.jupiter.api.Assertions.assertDoesNotThrow; +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertThrows; +import static org.junit.jupiter.api.Assertions.assertTrue; + +/** + * Covers {@code HoodieDeltaStreamerTestBase.TestHelpers#waitTillCondition}, the helper every + * continuous-mode deltastreamer test waits on. + * + * <p>HUDI-6843 is a flaky timeout in that wait whose only output was + * {@code java.util.concurrent.TimeoutException} at this method, with no indication of which assertion in + * the condition never held - the condition's error was logged at debug and discarded. That is why every + * report of the flake looks the same and none of them is actionable. + */ +class TestWaitTillCondition { + + /** A deltastreamer future that never finishes, as a continuous-mode job would be. */ + private static final Future<?> RUNNING = new CompletableFuture<>(); + + /** + * The helper polls every 2s, so the timeout has to leave room for several evaluations. A value close to + * one interval would make this test itself flaky on a loaded machine - if the worker started late and the + * first evaluation landed after the timeout, nothing would have been recorded to report. + */ + private static final int TIMEOUT_WITH_SLACK_SECS = 15; + + @Test Review Comment: Renamed to `CONDITION_TIMEOUT_SECS` in `1d01b62`. Agreed the Javadoc already carries the reasoning, so the name does not need to. All three usages moved together (the declaration, the call, and the assertion on the message that reuses it, so the value and the expected text still cannot drift apart). ########## hudi-utilities/src/test/java/org/apache/hudi/utilities/deltastreamer/HoodieDeltaStreamerTestBase.java: ########## @@ -763,22 +766,54 @@ static HoodieInstant assertCommitMetadataForIncrSource(String expected, String t return lastInstant; } + /** + * Polls {@code condition} until it holds, the deltastreamer future finishes, or the timeout expires. + * + * <p>On timeout the last error the condition threw is attached to the failure. Without it the only + * output is a bare {@link TimeoutException} pointing at this method, which says nothing about which + * assertion never held - the reason HUDI-6843 stayed open: every report of it looks identical. + */ static void waitTillCondition(Function<Boolean, Boolean> condition, Future dsFuture, long timeoutInSecs) throws Exception { - Future<Boolean> res = Executors.newSingleThreadExecutor().submit(() -> { - boolean ret = false; - while (!ret && !dsFuture.isDone()) { - try { - Thread.sleep(2000); - ret = condition.apply(true); - log.info("Condition completed successfully"); - } catch (Throwable error) { - log.debug("Got error waiting for condition", error); - ret = false; + AtomicReference<Throwable> lastError = new AtomicReference<>(); + ExecutorService executor = Executors.newSingleThreadExecutor(); + try { + Future<Boolean> res = executor.submit(() -> { + boolean ret = false; + while (!ret && !dsFuture.isDone() && !Thread.currentThread().isInterrupted()) { + try { + Thread.sleep(2000); + ret = condition.apply(true); + if (ret) { + log.info("Condition completed successfully"); + } + } catch (InterruptedException interrupted) { + // shutdownNow below interrupts this thread once the wait has given up. Thread.sleep clears + // the interrupt flag when it throws, so catching this with everything else would re-enter + // the loop and keep polling forever. Restore the flag and stop; this is not a condition + // failure, so it is deliberately not recorded as one. + Thread.currentThread().interrupt(); + break; + } catch (Throwable error) { + lastError.set(error); + ret = false; + } } + return ret; + }); + try { + res.get(timeoutInSecs, TimeUnit.SECONDS); + } catch (TimeoutException e) { + Throwable last = lastError.get(); + throw new AssertionError(String.format( Review Comment: Done in `1d01b62` — `cause` and `detail` are locals now: ```java } catch (TimeoutException e) { Throwable last = lastError.get(); String detail = last == null ? "The condition returned false without throwing, so there is no further detail." : "The last failure it reported was: " + last; Throwable cause = last == null ? e : last; throw new AssertionError( String.format("Condition was not met within %d seconds. %s", timeoutInSecs, detail), cause); } ``` Reads better, and it makes the two branches independently obvious: the message explains the absence of detail, while the cause falls back to the `TimeoutException` so the failure is never thrown with a null cause. Re-verified after both changes rather than assuming a rename and an extraction were safe: `TestWaitTillCondition` 4 green, checkstyle 0, apache-rat 0. I also re-ran the non-vacuity check by removing just the interrupt handling again, and `pollingStopsOnceTheWaitHasGivenUp` still fails with `expected: <2> but was: <4>`, so the extraction did not weaken the test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
