-
Type:
Bug
-
Resolution: Done
-
Priority:
Minor - P4
-
None
-
Affects Version/s: 1.8.3
-
Component/s: None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
The following code snippet illustrates curious behaviour;
var srv = new MongoClient( "mongodb://Boomtime:27017" ).GetServer(); var binfo = srv.BuildInfo; Console.WriteLine( "via .BuildInfo: {0}", null == binfo ? "[null]" : binfo.VersionString ); var resbi = srv.GetDatabase( "test" ).RunCommand( "buildInfo" ); Console.WriteLine( "via .RunCommand: {0}", resbi.Response["version"] ); var redux = srv.BuildInfo; Console.WriteLine( "via .BuildInfo: {0}", null == redux ? "[null]" : redux.VersionString );
Example output of running the code;
via .BuildInfo: [null] via .RunCommand: 2.4.6 via .BuildInfo: 2.4.6
If .BuildInfo is queried as the first order of business on a new server connection, then it appears to always yield null. After some other, possibly unrelated, commands have returned successfully, the .BuildInfo is now populated.
A value of null for BuildInfo on a valid connection is unexpected and should be documented if intended.
Assuming that behaviour is correct, the library now lacks a signal to indicate when the member has transitioned to a valid state. Which in turn requires polling or knowledge of the implementation to be able to make use of it.
In practice, it is not clear how to make robust use of this member.