Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-13961

Investigate changes in SERVER-20547: Expose the reason an operation fails document validation

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.9.0
    • Component/s: manual, Server
    • Labels:
      None
    • Last comment by Customer:
      true
    • Sprint:
      ServerDocs2020: Nov17 - Nov 24, ServerDocs2020: Nov24 - Dec1, ServerDocs2020: Dec1 - Dec8, ServerDocs2020: Dec8 - Dec15, ServerDocs2020: Dec15 - Jan 5, ServerDocs2020: Jan5 - Jan12, ServerDocs2020: Jan12 - Jan19, ServerDocs2020: Jan19 - Jan26

      Description

      Description

      Downstream Change Summary

      When an operation fails document validation, the server will now produce a detailed BSONObj which explains why the document failed to match against the collection's validator expression. When the validator's validatorAction is set to 'error', this detailed error will be included in the server's response to the client under the 'errInfo' field. Similarly, when the validator's validationAction is set to 'warn',the detailed error will be output as part of a log message under the 'errInfo' field.

      Description of Linked Ticket

      Issue Status as of October 21, 2020

      Summary
      Operations which fail document validation when the collection validator’s validationAction is set to ‘error’ will now return an error of the form:

      {
      	"n" : 0,
      	"writeErrors" : [
      		{
      				“index”: 0,
        		    		"code" : 121,
                			“errInfo”: {<object describing reason(s) for failure>},
        				"errmsg" : "Document failed validation"
         		}
      	],
      		“ok”: 1
      }
      

      When the validationAction is set to ‘warn’, a message of the following form will be written in the logs:

      {"t":{"$date": <date>},"s":"W",  "c":"STORAGE",  "id":20294,   "ctx":"conn","msg":"Document would fail validation","attr":{"namespace":<namespace>,"document":<document which failed validation>,"errInfo":<object describing the reason(s) for failure>}}
      

      In both cases, the ‘errInfo’ field contains a structured error object that describes why a particular document failed validation.

      Example
      To get a sense of what these detailed errors look like, suppose the following validator expression is set on a collection named ‘students’:

       {$jsonSchema: {
      	bsonType: "object",
      	required: [ "name", "year", "major", "address" ],
      	properties: {
      		name: {
      			bsonType: "string",
      			description: "must be a string and is required"
      		},
      		year: {
      			bsonType: "int",
      			minimum: 2017,
      			maximum: 3017,
      		 	description: "must be an integer in [ 2017, 3017 ] and is required"
      		},
      		major: {
      			enum: [ "Math", "English", "Computer Science", "History", null ],
      			description: "can only be one of the enum values and is required"
      		},
      		gpa: {
      			bsonType:  "double" ,
      			description: "must be a double if the field exists"
      		},
      		address: {
      			bsonType: "object",
      			required: [ "city" ],
      			properties: {
      	 			street: {
      					bsonType: "string",
      					description: "must be a string if the field exists”
      				},
      				city: {
      					bsonType: "string",
      				"description": "must be a string and is required"
      				}
      			}
      		}
      	}
      }
      

      Attempting to insert the document {name: “Mihai”, year: 2019, major: “Computer Science”} will produce the following error under the ‘errInfo’ field:

      "errInfo" : {
      	"failingDocumentId" : ObjectId("5f85f78bccef9666ae09c3c1"),
      		"details" : {
      			"operatorName" : "$jsonSchema",
      			"schemaRulesNotSatisfied" : [
      				{
      					"operatorName" : "properties",
      					"propertiesNotSatisfied" : [
      						{
      							"propertyName" : "year",
      							"details" : [
      								{
      									"operatorName" :"bsonType",
      									"specifiedAs" : {
      										"bsonType" : "int"
      									},
      									"reason" : "type did not match",
      									"consideredValue" : 2019,
      									"consideredType" : "double"
      								}
      							]
      						}
      					]
      				},
      				{
      					"operatorName" : "required",
      					"specifiedAs" : {
      						"required" : [
      							"name",
      							"year",
      							"major",
      							"address"
      						]
      					},
      					"missingProperties" : [
      						"address"
      					]
      				}
      			]
      		}
      }
      

      The detailed error describes why the document failed validation: the value specified for the ‘year’ field was of the wrong type and the ‘address’ field is required, but was missing.

      Version Information
      This feature will be available starting in version 4.9.0 once the upgrade (including upgrading the FCV) is fully complete.

      We will provide a link to the reference page for this feature in the online documentation when it becomes available.

      Original Description

      When documents fail validation, there is no feedback as to what failed.

      It should be possible to perform an update or insert operation and find out what specific predicate in the validator document cause the operation to fail.

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dave.cuthbert Dave Cuthbert
              Reporter:
              backlog-server-pm Backlog - Core Eng Program Management Team
              Participants:
              Last commenter:
              Dave Cuthbert Dave Cuthbert
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since reply:
                28 weeks ago
                Date of 1st Reply: