[Enhancement]: Fails the wait when the container stops

[frozenbonito]

Proposal

Some strategies assume the container is running.
However, a container may terminate due to an unexpected error, etc. Even in this case, testcontainers-go will keep waiting until the timeout.
It might be a good idea to check the status of the container while polling and return an error if it was stopped.

Example:

In the following code, mysql container immediately stops due to missing environment variables, but wait.ForSQL continues to wait until the timeout.

package main

import (
	"context"
	"log"
	"net"

	"github.com/docker/go-connections/nat"
	"github.com/go-sql-driver/mysql"
	"github.com/testcontainers/testcontainers-go"
	"github.com/testcontainers/testcontainers-go/wait"
)

func main() {
	ctx := context.Background()

	req := testcontainers.ContainerRequest{
		Image: "mysql:8.0",
		Env: map[string]string{
			"MYSQL_DATABASE": "app",
			"MYSQL_USER":     "user",
			"MYSQL_PASSWORD": "password",
			// "MYSQL_ALLOW_EMPTY_PASSWORD": "yes",
		},
		ExposedPorts: []string{"3306/tcp"},
		WaitingFor: wait.ForSQL("3306", "mysql", func(host string, port nat.Port) string {
			cfg := mysql.NewConfig()
			cfg.Net = "tcp"
			cfg.Addr = net.JoinHostPort(host, port.Port())
			cfg.DBName = "app"
			cfg.User = "user"
			cfg.Passwd = "password"
			return cfg.FormatDSN()
		}),
	}

	container, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
		ContainerRequest: req,
		Started:          true,
	})
	if err != nil {
		log.Fatal(err)
	}
	defer container.Terminate(ctx)
}

[mdelapenya]

I like this idea, thanks for the proposal.

@HofmeisterAn @cristianrgreco @eddumelendez are you doing this check internally in the wait strategy for each implementation language?

[eddumelendez]

I like this too! Indeed in tc-java there is no fail fast on the wait strategies. However, there is a diagnosis about what's the reason about the failure after the wait strategies have failed https://github.com/testcontainers/testcontainers-java/blob/6fe954ab940ccb674d85aca543fe4c979e8932f0/core/src/main/java/org/testcontainers/containers/GenericContainer.java#L484-L509

[mdelapenya]

@frozenbonito I've checked that in wait.ForExit and wait.ForHealth already checks for the container state. This is something we would like to extend to the other wait strategies, right? Would you like to participate in an eventual PR?

[frozenbonito]

Yes, it can be achieved in a way similar to wait.ForExit.
I'd like to work on it.