fluss-test-cluster stop reports success but leaves containers running

[beryllw]

Search before asking

• I searched in the issues and found nothing similar.

Please describe the bug 🐞

Description

cargo run -p fluss-test-cluster -- stop prints Cluster stopped. but the cluster's containers keep running. The same root cause also breaks start idempotency.

Steps to reproduce

On a host where the docker command resolves to a different container runtime than the one testcontainers connects to (e.g. Podman exposed at /var/run/docker.sock, while docker is an OrbStack shim with its own socket):

cargo run -p fluss-test-cluster -- start
podman ps            # zookeeper / coordinator / tablet containers are Up
cargo run -p fluss-test-cluster -- stop
podman ps            # still Up — nothing was removed

Root cause

start and the teardown/existence checks use two different mechanisms that can point at different daemons:

• Container creation goes through testcontainers (image.start().await → AsyncRunner::start), which connects via its embedded client to the daemon resolved from DOCKER_HOST / docker context / ~/.testcontainers.properties (here: Podman at /var/run/docker.sock).
• Container teardown and existence checks (stop_cluster, FlussTestingCluster::stop, all_containers_exist, and the start pre-clean) shell out to the docker CLI binary, which resolves to whatever runtime that binary defaults to (here: OrbStack).

Consequences:

1. stop removes nothing — it looks for the cluster's containers on the wrong daemon, finds none, and the Ok from a non-zero/empty CLI call is silently swallowed, so it still reports Cluster stopped.
2. start is not idempotent — all_containers_exist (also via the CLI) always returns false, so a repeat start tries to recreate containers whose names already exist on the testcontainers daemon, hitting a name conflict.

Solution

Manage containers via testcontainers' Docker client so start/stop share one runtime internally for image.start() — so teardown/existence checks inherit testcontainers' full daemon resolution (DOCKER_HOST, docker context, ~/.testcontainers.properties).

Are you willing to submit a PR?

• I'm willing to submit a PR!