beryllw opened a new issue, #623:
URL: https://github.com/apache/fluss-rust/issues/623

   ### Search before asking
   
   - [x] I searched in the 
[issues](https://github.com/apache/fluss-rust/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?
   
   - [x] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to