[Bug]: (Weird) issue resolving images since v2.0.2

[snazy]

Module

CrateDB

Testcontainers version

2.0.2

Using the latest Testcontainers version?

Yes

Host OS

Linux (GitHub, ubuntu-24.04)

Host Arch

x86

Docker version

28.0.4

What happened?

Renovate created a version-bump PR to v2.0.2 and since then one of our tests fails. v2.0.1 works fine.

That particular test is a bit special, as it also involves a couple DockerClient interactions. All other tests that use testcontainers work fine - only this particular one fails with 2.0.2.

The test fails in GH workflows with the message No such image: .... The image name is resolved here to the version managed by Revovate here.

The image in question definitely exists, and the test passes locally for me. However, I am using Podman locally, so my local env is not exactly the same as the GH runner environment. Detailed docker info is here.

I tried v2.0.1 with the newer dockerjava version 3.7.0 in this PR - passes.
I also tried v2.0.2 with the older dockerjava version 3.6.0 in this PR - fails as well.

Relevant log output

(links above)

Additional Information

No response

[eddumelendez]

Have you been able to reproduce the issue?

There are no changes related to pulling image.

[snazy]

Have you been able to reproduce the issue?

Not really. It fails 100% in GH runners and 0% locally, which is totally odd.

[taole33]

I tried to reproduce this issue here.
But build succeeded , I was unable to reproduce it.

[eddumelendez]

We also run tests using gradle projects on GHA, so, I am not able to reproduce this.

[snazy]

Fair, I totally understand.
Maybe I can craft a reproducer, but it's a tricky one that I do not understand at all.

[snazy]

This is really strange, and I still couldn't figure out why it's failing with the version bump.

Interesting observations:
Running the (affected) test alone in CI works fine. If the test's ran with other tests, it fails. It seems that the list-container command dockerClient.listImagesCmd().withImageNameFilter(image).exec().isEmpty() doesn't yield true in those cases. No clue why 🤷 - image was always docker.io/redocly/cli:2.14.0.

I tried to pass new RemoteDockerImage(imageName).get() to dockerClient.createContainerCmd() (instead of image) and let TC pull the image if necessary - and that seems to work. I suspect that there's something else that breaks this for exactly our test case.

[eddumelendez]

Thanks for sharing! can you try just using redocly/cli:2.14.0, dropping the docker.io/?

[snazy]

Thanks for sharing! can you try just using redocly/cli:2.14.0, dropping the docker.io/?

Weird, removing the registry prefix doesn't change anything 🤷