Inserting improperly-encoded string data into a collection can in some cases bypass BSON sanity checks and end up writing data to the database that results in a server exception whenever you attempt to read the inserted row from the database.

Attempting an upsert with the invalid data when the database doesn't exist results in the connection simply dropping. Attempting an insert (whether or not the DB exists yet) results in invalid data being written to the DB.

This is recoverable from by performing a compact of the affected collection, but it results in the loss of the entire document containing the bad data. In the best case, I'd expect mongo to save the string data as-is and reconstitute it byte-for-byte, but since I don't expect the DB saves encoding information, this would probably need to be a driver-level fix that would reject any attempt to write invalid UTF-8 to the database.

I saw that a similar issue was reported for the PHP driver, and was fixed by preventing invalid UTF-8 from being written to the database. Since this is fundamentally an issue with string encodings being munged, and mongod has no concept of alternate encodings, this has to be a driver fix. A core fix would be nice (at least for safe writes), but wouldn't cover all cases, since non-safe writes wouldn't ever see that the write has failed.