Skip to content

Conversation

@nook0110
Copy link

@nook0110 nook0110 commented Sep 24, 2025

I think some wrong solutions (for example my first one) can rely on the 'server' starting before 'clients'. I propose a crutch for this. It can catch some "naive" solutions

@lodthe
Copy link
Collaborator

lodthe commented Sep 26, 2025

You should never expect server is started before clients. Even depends_on doesn't guarantee that. It guarantees the container start order, but you have to add extra steps to verify that server is ready to accept and process requests, and only after that start client containers. Not sure if it's possible to combine depends_on and readiness probes in docker.

The correct way to handle that is to add retries on the client side / or set up "restart always" policy for clients. Clients should gracefully handle temporary server's unavailability.

@nook0110
Copy link
Author

nook0110 commented Sep 26, 2025

You should never expect server is started before clients. Even depends_on doesn't guarantee that. It guarantees the container start order, but you have to add extra steps to verify that server is ready to accept and process requests, and only after that start client containers. Not sure if it's possible to combine depends_on and readiness probes in docker.

The correct way to handle that is to add retries on the client side / or set up "restart always" policy for clients. Clients should gracefully handle temporary server's unavailability.

@lodthe

That's the reason of this pr... it makes the server container start AFTER clients, so it will catch some wrong solutions

@nook0110 nook0110 changed the title Add depend_on in docker compose Add depends_on in docker compose Sep 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants