I've noticed an issue that I can reliably reproduce on Docker for Mac 2.0.0.2, but which does not appear on CI.
org.testcontainers.utility.DirectoryTarResourceTest#simpleRecursiveFileTest will fail ~80% of the time for me. This particular test uses a short-lived container comprising a cat CMD and with OneShotStartupCheckStrategy. The test attaches a ToStringConsumer to logs and waits for the end of stdout logs to be reached.
Some of the time, when the test passes, the log stream callback events are onStart, onNext (containing the desired stdout line) and onComplete.
After adding a little extra instrumentation, it appears that most of the time the log stream callback events are onStart, onComplete. onNext is never fired.
In this situation the test fails. However, when attempting to read the logs later, the correct log message is found.
My hypothesis is that this version of Docker automatically triggers the onComplete event at container exit even if there are unflushed stdout/stderr frames.
I've noticed an issue that I can reliably reproduce on Docker for Mac 2.0.0.2, but which does not appear on CI.
org.testcontainers.utility.DirectoryTarResourceTest#simpleRecursiveFileTestwill fail ~80% of the time for me. This particular test uses a short-lived container comprising acatCMD and withOneShotStartupCheckStrategy. The test attaches aToStringConsumerto logs and waits for the end of stdout logs to be reached.Some of the time, when the test passes, the log stream callback events are
onStart,onNext(containing the desired stdout line) andonComplete.After adding a little extra instrumentation, it appears that most of the time the log stream callback events are
onStart,onComplete.onNextis never fired.In this situation the test fails. However, when attempting to read the logs later, the correct log message is found.
My hypothesis is that this version of Docker automatically triggers the
onCompleteevent at container exit even if there are unflushed stdout/stderr frames.