Sporadische Timing-Fehler in dem Test ausgeschlossen

* Ohne die Verzögerung des Pollings von Awaitility schlug der neue
  Test manchmal fehl, wenn der letzte Fehler, der auf die DLQ verschoben
  werden musste, genau auf dem letzten verarbeiteten Datensatz aufgetreten
  ist.
* Der Timeing-Fehler kann gezielt ausgelöst werden, wenn das Poll-Intervall
  quasi auf Null (1 Nanosekunde) gesetzt wird.
* Das zurückhaltendere Polling führt dazu, dass der Timing-Fehler im Test
  nicht mehr auftritt.
* _Schluss:_ Das Tooling war durch das penetrannte Polling von Awaitility
  einfach so überlastet, dass der Offset-Commit nicht schnell genug
  angekommen ist.

diff --git a/src/test/java/de/juplo/kafka/ApplicationTests.java b/src/test/java/de/juplo/kafka/ApplicationTests.java
index 43a4f6124d8fa931b0791149f84227959352ad2d..7ec73f353278aa29f8f76ddf7b1f3eeac7896422 100644 (file)
--- a/src/test/java/de/juplo/kafka/ApplicationTests.java
+++ b/src/test/java/de/juplo/kafka/ApplicationTests.java
@@ -153,6 +153,7 @@ class ApplicationTests
 
                await("Offsets committed")
                                .atMost(Duration.ofSeconds(10))
+                               .pollDelay(Duration.ofSeconds(1))
                                .untilAsserted(() ->
                                {
                                        checkSeenOffsetsForProgress();