No, not to my knowledge. The check to make sure that the client and server have compatible versions (i.e., they have the same major and minor version, so, for example, a 6.3.21 server and 6.3.12 client are compatible, but not a 6.3.21 server and 6.2.x client) is done within the C client and doesn’t expose anything to the higher-level language binding.
The reason the client is stalling, btw, is somewhat of a quirk, but the idea is that it hangs rather than throwing an error in order to support a “blue/green server upgrade model”, the idea being that if you want to upgrade FDB server from, say, 6.2.x to 6.3.x, you can deploy two sets of applications, one with the 6.2 client and one with the 6.3 client. Until the upgrade happens, the 6.3 clients will essentially poll the servers, trying to detect an upgrade, but they won’t successfully connect until the FDB server upgrade actually completes. However, in the past few years, the FDB team has been rethinking whether this behavior is optimal (over, say, propagating a client/server version mismatch error, which would be useful even in a blue/green deployment, as the application could use this to know whether to direct requests to either the older or newer clients, and would also make client misconfiguration easier to detect). I can’t find any issue directly addressing it, though.
Work has completed to allow users to load multiple client versions which are then chosen at runtime based on the server version so that they don’t need a blue/green client deployment on server upgrade (see: Using FoundationDB Clients — FoundationDB 6.3), and there’s also work ongoing under the umbrella of “Multi-version client 2.0” (see: Multi-version client 2.0 · Issue #3966 · apple/foundationdb · GitHub) to make it easier to detect things like the server version by using stable endpoints, including even uploading/downloading client libraries in system keyspaces (see: Operations to upload and manage client binaries in the system keyspace by sfc-gh-vgasiunas · Pull Request #5694 · apple/foundationdb · GitHub).