Microservice cannot connect to Micro Storage when Docker Desktop is above 4.30.0

[allister-beamable]

Describe the Bug

After having upgraded Docker Desktop, whenever my C#MS invokes Storage stuff, there is a timeout error. First the client/service call times out at 10 seconds, then there is an error in the C#MS log after 30 seconds.

Exception "TimeoutException": "A timeout occurred after 30000ms selecting a server using CompositeServerSelector{ Selectors = MongoDB.Driver.MongoClient+AreSessionsSupportedServerSelector, LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 }, OperationsCountServerSelector }. Client view of cluster state is { ClusterId : \"1\", Type : \"Unknown\", State : \"Disconnected\", Servers : [{ ServerId: \"{ ClusterId : 1, EndPoint : \"Unspecified/gateway.docker.internal:12101\" }\", EndPoint: \"Unspecified/gateway.docker.internal:12101\", ReasonChanged: \"Heartbeat\", State: \"Disconnected\", ServerVersion: , TopologyVersion: , Type: \"Unknown\", HeartbeatException: \"MongoDB.Driver.MongoConnectionException: An exception occurred while opening a connection to the server.

The MongoDB database is still reachable by tools like mongosh and MongoDB Compass, by pointing at mongodb://<username>:<password>@localhost:12101; the only problem seems to be the connection from C#MS to Storage.

To Reproduce

1. Have a Unity Beamable project with at least one C#MS and at least one Micro Storage created from within Unity.
2. Upgrade Docker Desktop to 4.31.0 or higher.
3. Run the storage and the microservice.
4. Enter playmode and do something that invokes Storage in the C#MS.

Expected Behavior

• Database operations succeed and the C#MS responds to the client in a timely fashion.

Actual Behavior

• The storage call hangs for 30 seconds, causing a 10-second timeout in C#MS activity, and logging the MongoDB.Driver TimeoutException to the service log.

Metadata

• SDK version: Beamable Unity SDK 1.19.22
• Engine version: Unity 2021.3.27f1 (and probably others)
• Operating System: macOS, Windows

Additional Context

Customers are able to work around this by avoiding local storage in favor of remotely-deployed Micro Storage.

[cdhanna]

I think another Beamable employee found that perhaps the local docker dns named has changed? In the GetLocalConnectionString method, we have a hardcoded default host value as "gateway.docker.internal". Perhaps that has changed?

In Unity 1.19.x, check the MicroserviceReflectionCache.GetConnectionString method; it also has the same reference to gateway.docker.internal

[cdhanna]

to actually fix this, we'll likely need to introduce a version number check for docker, or, find a way to read the host from somewhere

[allister-beamable]

There has gotta be a way to implement dynamic discovery. When services are run with Docker Compose, they magically get hostname entries in the network with which the containers are launched.