-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Component/s: None
-
None
When a command fails, mongos sometimes returns a subdocument called "raw", with errors from each shard:
mongos> db.stats('foo') { "ok" : 0, "errmsg" : "{ shard0/localhost:4000,localhost:4001: \"scale has to be a number > 0\", shard1/localhost:4002,localhost:4003: \"scale has to be a number > 0\" }", "raw" : { "shard0/localhost:4000,localhost:4001" : { "ok" : 0, "errmsg" : "scale has to be a number > 0" }, "shard1/localhost:4002,localhost:4003" : { "ok" : 0, "errmsg" : "scale has to be a number > 0" } } }
As you can see, the raw error messages are often more legible than the top-level message, so PyMongo tries to be clever and use one of the shards' error messages if it can find one.
But here's the rub: if a shard is down, mongos can return an empty error document in "raw" (SERVER-15428). After I take down the primary of shard0:
mongos> db.stats('foo') { "ok" : 0, "errmsg" : "{ shard0/localhost:4000,localhost:4001: \"result without error message returned : {}\", shard1/localhost:4002,localhost:4003: \"scale has to be a number > 0\" }", "raw" : { "shard0/localhost:4000,localhost:4001" : { }, "shard1/localhost:4002,localhost:4003" : { "ok" : 0, "errmsg" : "scale has to be a number > 0" } } }
PyMongo throws an exception trying to parse this (PYTHON-766).
*Questions:* Does your driver try to parse the "raw" subdocument from mongos? If so, does your driver handle an empty raw error reasonably well? Do you test it?
Validate this ticket if your driver does *not* try to parse raw errors from mongos at all, or validate it if you have a test that demonstrates your driver can parse empty raw errors.
- depends on
-
PYTHON-766 KeyError parsing error response from mongos
- Closed
- is related to
-
SERVER-15428 Empty "raw" error from mongos when a shard has no primary or is down
- Closed
-
PYTHON-2381 Remove handling of "raw" field in command errors
- Backlog