Closed ShaneHarvey closed 7 years ago
Interesting. Should mongo-orchestration use bson.json_util to avoid issues like this in the future?
Maybe it's better not to include raw responses from the server (e.g. from buildinfo
) in responses from mongo-orchestration; instead we can run these commands from a driver, if it's needed. Then mongo-orchestration won't need to worry about trying to JSONify anything that has unserializable types in it.
As far as buildinfo
goes, the way we use mongo-orchestration means we know the build info ahead of time, so we probably don't need to include its output at all in responses from mongo-orchestration.
However, I don't know if someone else may be using this output for their tests right now.
Since MongoDB 3.2, the
buildinfo
command response contains"$gleStats": {"lastOpTime": bson.Timestamp(...), "electionId": bson.ObjectId(...)}
when run on a member of a replica set shard. This causes GETS on/servers/<server_id>
to fail because these BSON types are not JSON serializable.Repro: Launch mongo-orchestration with MongoDB 3.4 or 3.2. Start a sharded cluster with a replica set shard. GET on
/servers/<shard server id>
:Mongo-orchestartion log:
While simply removing
$gleStats
fixes the problem now, a more future-proof solution would be to use MongoDB Extended JSON for responses but I think that change should happen after PyMongo implements the spec.