[SERVER-25004] Collection validator rule is mismatched across nodes after failed collMod command Created: 11/Jul/16  Updated: 12/Dec/16  Resolved: 23/Sep/16

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 3.2.7, 3.3.9
Fix Version/s: 3.2.12, 3.3.15

Type: Bug Priority: Critical - P2
Reporter: Kamran K. Assignee: Robert Guo (Inactive)
Resolution: Done Votes: 0
Labels: collMod
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
related to SERVER-25196 collMod should support writeConcern Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.2
Sprint: TIG 18 (08/05/16), TIG 2016-09-19, TIG 2016-10-10
Participants:
Linked BF Score: 0

 Description   

This bug affects 3.2.7 and master. It leads to a primary and secondary having different collection validation rules:

----
Collection info for primary
----
[
	{
		"name" : "collmod",
		"options" : {
			"validator" : {
				"a" : {
					"$eq" : "z"
				}
			},
			"validationLevel" : "off",
			"validationAction" : "error"
		}
	}
]
 
----
Collection info for secondary
----
 
[
	{
		"name" : "collmod",
		"options" : {
			"validator" : {
				"a" : {
					"$eq" : "z"
				}
			},
			"validationLevel" : "strict",
			"validationAction" : "error"
		}
	}
]



 Comments   
Comment by Githook User [ 12/Dec/16 ]

Author:

{u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}

Message: SERVER-25004 isolate parsing logic in collmod

(cherry-picked from commit 948f978a782167ddb6efec9f9adf5ad317eb4d0d)
Branch: v3.2
https://github.com/mongodb/mongo/commit/37627eca43dcb19def199e50fa7673ab8710d7a4

Comment by Githook User [ 23/Sep/16 ]

Author:

{u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}

Message: SERVER-25004 isolate parsing logic in collmod
Branch: master
https://github.com/mongodb/mongo/commit/948f978a782167ddb6efec9f9adf5ad317eb4d0d

Comment by Geert Bosch [ 19/Jul/16 ]

As discussed, collMod should be changed to first parse the command into a request data structure. Then all actual in-memory changes should have rollback actions (preferably in catalog modification code, not directly in collMod.

Comment by Scott Hernandez (Inactive) [ 11/Jul/16 ]

This seems to be independent of replication, and setting some state in memory during the failed coll_mod. I expect we need to add a recovery_unit onAbort handler to undo changes before the failure event in the coll_mod command.

Also, we may want to include all fields for the collection if they are set so this could more easily be diagnosed in the future, if my theory is correct.

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