I am quite sure that it would be robust if you would use it the way they write it in their documentation.
While in the documentation the overlay network is created on the cli with docker network create --driver=overlay --attachable openldap-net, you create it within a compose file. While the version of the documentation has a decoupled lifecycle and will exist until removal, your version is coupled to the lifecylce of docker compose AND adds an undesirable dependecy that leaves room for race condtions.
I would suggest to modify the network declaration in the master compose to match the current config of the node compose and then actualy do what the docs do: create the network from the cli. This should sort of most of the problems you introduced, if not all of them.
Arw you aware that custom bridge and overlay networks have build in service discovery, which is dns-based and allows to access other containers in the same network by their servicename?