Docker Compose Elasticsearch service and Java API Client 8.x startup readiness interoperability

A repeatable development environment is targeted using a Docker Compose Elasticsearch service with a pinned image tag and a named volume, together with an Elasticsearch Java API Client 8.x in the application build. The goal is consistent version alignment across developer machines for the cluster and the client library.

Version alignment is a documented constraint: the client major version should match the Elasticsearch major version for API compatibility, and the Docker image tag and client dependency are intended to be pinned in the project build file and compose definition. Network naming and container startup ordering are part of the integration boundary between Compose and the client.

The unresolved decision concerns readiness signaling. Docker Compose depends_on reflects container start, not cluster formation and shard allocation readiness. This creates uncertainty about when the Java API Client can safely issue requests in an automated test or application start sequence.

What signal defines Elasticsearch readiness for API calls in a Compose-based dev environment? How should version pinning be coordinated between the Docker image and the Java API Client dependency to maintain repeatability? What integration pattern avoids race conditions at the Compose to client boundary?