TypeEditor misapplies default primary type of child node to its parent when the child primary type is not set

Preconditions

• Child node's "after" state does not have a jcr:primaryType property
• TypeEditorProvider is created with strict=false to suppress the ConstraintViolationException for the missing jcr:primaryType property
• Parent node's effective type specifies a default type for the child's node name

Summary

This issue ultimately presented in an AEM author environment as a Sling Repository Initializer exception:

Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted throwable : javax.jcr.RepositoryException: Applying repoinit operation failed despite retry; set loglevel to DEBUG to see all exceptions. Last exception message was: Session.save failed: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001: /conf/rep:policy[[rep:GrantACE]]: No matching definition found for child node deny90 with effective type [rep:DenyACE]_ 

somehow the jcr:primaryType values for each segment of the relative path under /conf, rep:policy/allow78/rep:restrictions, had been saved to its parent. What should have been:

rep:policy(rep:ACL)/allow78(rep:GrantACE)/rep:restrictions(rep:Restrictions)

had been committed as

rep:policy(rep:GrantACE)/allow78(rep:Restrictions)/rep:restrictions(<not set>)

Additionally, the jcr:primaryType properties for rep:policy and allow78 HAD been set correctly in previous commit roots, but had been changed incorrectly in the same commit that created the rep:restrictions node. The same commit had also included changes to a list of linked principal names that could not be correlated with any artifact in the custom code or installed filevault packages.

After changing the jcr:primaryType properties directly in the mongodb database to allow the repository to complete its startup, further investigation determined that a Content Transfer Tool import had been executed just prior to the first appearance of this error in the server logs.

The fact that the rep:restrictions node had been persisted without a jcr:primaryType property strongly suggested that the corrupting change had not been made through the JCR API.

The other important detail is that the rep:glob property was properly saved to the rep:restrictions node as part of the same commit, which implies that the jcr:primaryType property is subject to some special treatment in this situation. 

These details led me to suspect that the TypeEditor is the source of this behavior.

The TypeEditor normally rejects a commit with a ConstraintViolationException when an "after" node state lacks a jcr:primaryType property, but it will instead only log this condition if the TypeEditorProvider is created with strict=false. I've confirmed that this is how the Content Transfer Tool importer constructs its root type editor.