[Enhancement]: Debug Messages should be calling arguments, when debug level is disabled

[ismurygin]

Module

MySQL

Proposal

I face the issue with MySQL, but I suppose that can be the case for other libs as well.
My case.
I create a custom MySQL image, which is stored on ECR.
I start it like

	private static CustomMysqlContainer createInstance() {
		String imageName = determineImageName(); // image name is from ECR
		try {
			log.info("Initializing CustomMysqlContainer with image: {}", imageName);
			CustomMysqlContainer instance = new CustomMysqlContainer(imageName);
			instance.withStartupAttempts(1).start();
			return instance;
		} catch (Exception e) {
			log.error("Failed to initialize CustomMysqlContainer with custom image: {}. Falling back to generic image.", imageName, e);
			return fallbackInstance(); // here standard image is created
		}
	}

So my expectation is that when a single attempt fails, the fallback is used.
What I see is that exception is thrown when debug message is going to be printed, in the class
org.testcontainers.containers.GenericContainer#doStart

    protected void doStart() {
        try {
            if (this.waitStrategy != DEFAULT_WAIT_STRATEGY) {
                this.containerDef.setWaitStrategy(this.waitStrategy);
            }

            configure();

            logger().debug("Starting container: {}", getDockerImageName()); // <-- here the error is happening

and process is locked in some kind of internal loop, which I can't fully understand
Exception trace:

2025-01-22T18:05:50.8718829Z Caused by: org.testcontainers.shaded.org.awaitility.core.ConditionTimeoutException: Condition org.testcontainers.images.RemoteDockerImage$$Lambda/0x00007f764c7052d8 was not fulfilled within 2 minutes.
2025-01-22T18:05:50.8719663Z 	at org.testcontainers.shaded.org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
2025-01-22T18:05:50.8720225Z 	at org.testcontainers.shaded.org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
2025-01-22T18:05:50.8720916Z 	at org.testcontainers.shaded.org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
2025-01-22T18:05:50.8721625Z 	at org.testcontainers.shaded.org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
2025-01-22T18:05:50.8722174Z 	at org.testcontainers.shaded.org.awaitility.core.ConditionFactory.until(ConditionFactory.java:954)
2025-01-22T18:05:50.8722678Z 	at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:105)
2025-01-22T18:05:50.8723255Z 	at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:33)
2025-01-22T18:05:50.8723715Z 	at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:20)
2025-01-22T18:05:50.8724119Z 	at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:41)
2025-01-22T18:05:50.8724576Z 	at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1362)
2025-01-22T18:05:50.8724977Z 	... 68 common frames omitted

My logging level is INFO

Testcontainers version: 1.19.8
My expectation: No errors is caused by debug messages.

It looks like logger factory is based on the docker image name, which throws exception in my case when no credentials is configured for ECR

    protected Logger logger() {
        return DockerLoggerFactory.getLogger(this.getDockerImageName());
    }

[eddumelendez]

Hi, latest versions have improved registry authentication. Could you try version 1.20.4?

[ismurygin]

Let me try, I suppose I found the place which makes the retries, which isn't possible to configure

org.testcontainers.images.RemoteDockerImage#resolve

            // The following poll interval in ms: 50, 100, 200, 400, 800....
            // Results in ~70 requests in over 2 minutes
            final PollInterval interval = IterativePollInterval
                .iterative(duration -> duration.multipliedBy(2))
                .startDuration(Duration.ofMillis(50));

It is the same in the version 1.20.4, so I suppose the same issue will be there. Is it possible to make it configurable and to fail after the first attempt?
Currently it is only possible to configure pull.timeout

    public Integer getImagePullTimeout() {
        return Integer.parseInt(getEnvVarOrProperty("pull.timeout", "120"));
    }

Update: Just checked, it is the same issue as with the previously used version