robertstam
The C# driver has MANY options that are nullable booleans, and they are all interpreted such that null means don't send this argument to the server. Changing the existing nullable boolean bypassDocumentValidation to non-nullable is a breaking change. Changing the behavior of the existing nullable boolean to interpret null and false to mean the same thing (i.e. don't send the value to the server) is more doable but it's confusing to have a nullable boolean when null doesn't mean anything.
Or rather, null doesn't mean anything special... null would be a synonym for false if we made this change. But that is totally unexpected behavior when compared to how nullable boolean arguments in general work.
mbroadst
@robertstam can you please open a SPEC ticket recommending language changes? It looks like y'all decided this wasn't a good idea for C#, and I think drivers should be consistent here
jmikola
I don't think anyone is proposing changing the option to non-nullable (if that was even a concern). I'd argue the only unexpected thing with changing a driver to comply with DRIVERS-450 is that a user would no longer see bypassDocumentValidation=false sent across the wire (e.g. APM, WireShark). Users probably don't even need to know that we'll totally ignore the option if they supply false.
mbroadst
My read on Jeffs comment earlier in #driver-devs is that us ignoring them explicitly setting it to false is a potential issue. @jeff did I misunderstand?
jeff
No, that’s accurate. But it’s also unlikely that the server will change the default value for this option, so it’s not a huge practical concern. In terms of APM assertions for future CRUD tests, inconsistency here will cause a problem if we add a test where the operation explicitly sets bypassDocumentValidation to false, and then asserting that the command sent to the server does not have that field. Not a problem right now, but could be in the future.