Hmm....

.withCommand("/bin/sh", "-c", "echo -n 'stdout' && echo -n 'stderr' 1>&2")

&& here should guarantee that stderr will follow after stdout. It looks more like a bug to me that the test is failing from time to time

I also fixed this test in #1345 since it was failing for me sporadically (even on my local machine) , are you sure docker-java logContainerCmd guarantees order?

It must be. I think we need to investigate it further, I'm afraid there is a bug

I think it's actually down to the flush decision in the shell (sh). Because the test is not running with a TTY apparently. With TTY, stdout is line-buffered; without TTY, stdout is fully buffered (and we'd be at the mercy of the timing of the shell's decision to flush.

Have a look at this (I've annotated for clarity):

bash-3.2$ while true; do
> docker run alpine /bin/sh -c "echo -n 'stdout' && echo -n 'stderr' 1>&2"
> echo
> sleep 0.1
> done
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stderrstdout   <--
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stdoutstderr
stderrstdout   <--
stdoutstderr
stdoutstderr
stderrstdout
stdoutstderr
...

Interestingly if we repeat this docker run with -t then the results come through perfectly ordered all the time. I'm not quite sure I understand this completely; echo -n ought to not be sending the newline characters that flush the stdout buffers. Regardless, this is the effect!

I guess we could modify this test to just use a TTY 🤔...

@rnorth
😱 TIL!
I wonder if this was the reason of flakiness of the log waiting strategy with some containers...

I support the idea of running this test with TTY, at least for the.... demo purpose :D Let's just put a comment above it about the flushing issue

Ergh, enabling TTY in these tests does something bizarre:

The three assertions results for the tests involving getLogs():

            '' does not equal expected 'stderr'

            'derr' does not equal expected 'stdout
stderr'

            'derr' does not equal expected 'stdout'

I think it's fair to say that there is a bug with getLogs() (or the data flow to it) when TTY is enabled!

@bsideup given that enabling TTY does even worse things for the log order, would you be OK for us to merge this as-is?

@rnorth I have really bad feeling about hiding this bug :(
But if we're not going to fix it, let's at least create a test for the order and mark it as ignored?