OneShotStartupCheckStrategy fails if the container is already gone

[bsideup]

Consider the following test:

    @Test(timeout = 5_000)
    public void testExitingContainer() {
        try (
            GenericContainer container = new GenericContainer<>()
                .withCreateContainerCmdModifier(it -> it.getHostConfig().withAutoRemove(true))
                .withStartupCheckStrategy(new OneShotStartupCheckStrategy())
        ) {
            container.start();
        }
    }

It will fail because the container exits immediately and OneShotStartupCheckStrategy receives NotFoundException.

The question is - what should we do? StartupStatus.SUCCESSFUL or StartupStatus.FAILED?

[rnorth]

Ergh. Yeah, the problem is that there's no right StartupStatus for this.

I think actually OneShotStartupCheckStrategy is not right - how about a new strategy? e.g. a strategy that checks that the container is no longer present (although this is a pretty useless check)?

In this case, short execution + autoremove, there's not much we can actually do to verify what happened, is there? It almost seems like a scenario worth avoiding altogether!

[bsideup]

As observed in #1327, Socket exits immediately if no ports are exposed, but the check fails due to some race condition. It seems that we can't easily avoid it.

[rnorth]

Got it - but hasn't #1328 avoided this?

[bsideup]

@rnorth there are more such places and races.
Another one - containerized Docker Compose, when commands exit faster than the check.
Also, we recommend OneShotStartupCheckStrategy for simple commands because there isn't anything to prevent it from failing.
Maybe we need a NoopStartupCheckStrategy ? :D

[rnorth]

Yeah, NoopStartupCheckStrategy was vaguely in my mind 😁

Still, do we need to use autoRemove? It seems like it causes two problems:

• This race condition
• It's impossible to tell whether the invocation succeeded or failed

[bsideup]

autoRemove here is to demonstrate the problem, but I was also thinking about adding it to our one-off commands like DockerCompose ones, because currently I see many exited compose containers during the execution

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[stale]

This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case.