[SERVER-17050] Error message for read-commands on secondary should suggest slaveOk Created: 26/Jan/15  Updated: 25/Jan/17  Resolved: 03/Mar/15

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.8.0-rc1
Fix Version/s: 3.1.0

Type: Bug Priority: Trivial - P5
Reporter: Kevin Pulo Assignee: Siyuan Zhou
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-15994 listIndexes and listCollections can b... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
  1. Start 2 node replica set
  2. Wait for members to be primary and secondary
  3. Connect to secondary
  4. Run listDatabases, listCollections, and listIndexes commands
Sprint: RPL 0 3/13/15
Participants:

 Description   

Since listDatabases, listCollections and listIndexes are commands that can work on a secondary with slaveOk, their error should indicate that.

Otherwise, the user might mistakenly believe that these commands are completely forbidden on secondaries.

SERVER-15994 changed the behaviour of listDatabases, listCollections and listIndexes to require the slaveOk bit to be set when run on secondaries. This makes sense: since they are effectively reads that can return stale data, they should require the user to state that this is okay by setting slaveOk.

However, the error they give is "not master":

> db.adminCommand("listDatabases")
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master" }
> db.adminCommand("listCollections")
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master" }
> db.adminCommand("listIndexes")
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master" }

This is misleading, because it is the error used for operations that only work on the primary, such as writes:

> db.foo.insert({})
WriteResult({ "writeError" : { "code" : undefined, "errmsg" : "not master" } })

Operations such as reads, which can work on a secondary if slaveOk is set, usually give the error "not master and slaveOk=false":

> db.foo.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }

Note that querying system.namespaces and system.indexes in earlier versions (what listDatabases, listCollections and listIndexes have replaced) also return an error that mentions slaveOk:

> db.system.namespaces.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }
> db.system.indexes.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }

Thus, the desired behaviour is simply to adjust the error message to include mention of slaveOk=false:

> db.adminCommand("listDatabases")
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master and slaveOk=false" }
> db.adminCommand("listCollections")
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master and slaveOk=false" }
> db.adminCommand("listIndexes")
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master and slaveOk=false" }



 Comments   
Comment by Githook User [ 03/Mar/15 ]

Author:

{u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}

Message: SERVER-17050 Error message for read-commands on secondary should suggest slaveOk
Branch: master
https://github.com/mongodb/mongo/commit/c809c0fd4668334ce39737ec9ff7de8d550a699f

Comment by Eric Milkie [ 26/Jan/15 ]

This is actually true of all commands that do reads and have slaveOverrideOk=true. Distinct and count have the same behavior, for example.

Generated at Thu Feb 08 03:43:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.