Fallback to amd64 on InternalServerErrorException during image pull

[Jaiswal-Devpriya]

No description provided.

[Jaiswal-Devpriya]

I investigated the failure path reported in #11782 and found that the existing fallback to linux/amd64 is only triggered for DockerClientException and NotFoundException.

In the reported case, some registries return an InternalServerErrorException with a message indicating that no image exists for the requested ARM64 architecture. Since that exception type was not included in the fallback path, Testcontainers would not attempt the existing linux/amd64 fallback.

I've updated the fallback logic to also handle InternalServerErrorException and added a regression test covering this behavior.

[MichaelLykkeStrand]

I’m concerned this changes the semantics of all pull-time InternalServerErrorExceptions.

Those errors are currently retried as possible transient registry/connection failures. With this change, any 500 causes the pull command to be reconfigured with linux/amd64, so a temporary registry error could accidentally make Testcontainers pull the amd64 image even when a native image exists.

I think the safer fix would be to expose an explicit image platform option and pass it through to PullImageCmd.withPlatform(...), rather than inferring amd64 fallback from all 500s.

[Jaiswal-Devpriya]

Thanks for the review @MichaelLykkeStrand. I agree with the concern about changing the semantics of all InternalServerErrorExceptions and potentially affecting the existing retry behavior for transient failures.

I'll rework the implementation to avoid inferring an amd64 fallback from generic 500 responses and investigate an explicit platform configuration approach that passes through to PullImageCmd.withPlatform(...).

I'll update the PR once I have a revised implementation and tests in place.

[Jaiswal-Devpriya]

Thanks for the feedback. I reworked the approach to avoid inferring an amd64 fallback from generic InternalServerErrorExceptions and to preserve the existing retry semantics for pull failures.

Instead, I added an explicit image platform option that is passed through to PullImageCmd.withPlatform(...), making platform selection opt-in rather than automatically triggered by a pull-time exception.

I've also added test coverage to verify that the configured platform is propagated to the pull command.