[SERVER-12465] write commands accept empty writeConcern document Created: 24/Jan/14  Updated: 06/Dec/22  Resolved: 05/Sep/19

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: 2.5.5
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Jeffrey Yemin Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

db version v2.5.5-pre-
2014-01-23T20:40:17.533-0500 git version: d91079d6d0d85b070c7d94376a441a7d41ae49f5


Issue Links:
Related
related to DRIVERS-131 Drivers should only send {w:1} if and... Closed
is related to SERVER-43185 write concern accepts malformed docum... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

This command:

> db.test.runCommand({insert : "test", documents : [{}], writeConcern : {} } )

returns:

{ "n" : 1, "ok" : 1 }

Expected result:

{
	"ok" : 0,
	"errmsg" : "'writeConcern' field is set to a document that is missing required fields",
	"code" : 9
}

Other unsupported fields or value types in the writeConcern document will generate the incorrect response as well:

> db.test.runCommand({insert : "test", documents : [], writeConcern : { wtimeout : true} } )
> db.test.runCommand({insert : "test", documents : [], writeConcern : { foo : 1} } )
> db.test.runCommand({insert : "test", documents : [], writeConcern : { j : false} } )  // not sure why this one is treated this way, as this is a legal value for j

The command also allows extra unsupported fields like "foo" below:

> db.test.runCommand({insert : "test", documents : [], foo : 1} )
{ "ok" : 1, "n" : 0 }

Not sure if this is the intended behavior.



 Comments   
Comment by Judah Schvimer [ 05/Sep/19 ]

Some drivers send empty write concern documents assuming this behavior. As a result, closing this as Works As Designed. SERVER-43185 is filed to address the bug that write concern accepts malformed documents.

Comment by Greg Studer [ 03/Feb/14 ]

Reopening per Jeff's comment, we should still return an "n" value.

Comment by Jeffrey Yemin [ 03/Feb/14 ]

greg_10gen We can change the spec, but the server would still be in violation, as it's not returning the "n" field.

Comment by Eliot Horowitz (Inactive) [ 03/Feb/14 ]

We should change the spec such that an empty document is the same as a missing field or null.

Comment by Scott Hernandez (Inactive) [ 24/Jan/14 ]

Yeah, I don't see the empty document meaning something (significantly) different, but if the spec says...

Comment by Jeffrey Yemin [ 24/Jan/14 ]

The spec indicates that a missing writeConcern field means to use the "default" write concern. Otherwise, the field should be set to a document indicating the explicit write concern to apply. For that reason, an empty document is non-sensical.

Comment by Scott Hernandez (Inactive) [ 24/Jan/14 ]

Maybe this is just a misunderstanding. There is a difference from no-write concern as you say and the empty write concern.

Comment by Scott Hernandez (Inactive) [ 24/Jan/14 ]

You do know about the "default" write concern as defined on the serve by the server/replica-set '(http://docs.mongodb.org/manual/reference/replica-configuration/#local.system.replset.settings.getLastErrorDefaults)...

Comment by Jeffrey Yemin [ 24/Jan/14 ]

The default write concern is indicated by not including the writeConcern field at all, not by sending an empty document. Also, {ok : 1} is not a valid response, as the "n" field is required if ok is 1.

Comment by Scott Hernandez (Inactive) [ 24/Jan/14 ]

This is the case of the default write concern, since no options are sent.

Is there something I missed?

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