[Content-EXIM] Better (or clear exception) handling when folder is not hippostd:folder, but hippostd:directory

org.onehippo.forge.content.exim.core.impl.WorkflowDocumentManagerImpl#getExistingDocumentPath(String) tries to find a folder node, of type hippostd:folder, which is fine since every content related folders are created as hippostd:folder since at least v10 for many reasons such as ordering.
However, it doesn't throw an exception or leave a meaning log when there's an interim directory which is of hippostd:directory. As a result, it's very hard to catch the problem from exception logs like the following:

[INFO] [talledLocalContainer]13:22:30.446 [pool-6-thread-1] ERROR o.o.f.c.e.c.i.WorkflowDocumentManagerImpl - Failed to obtain editable instance on document.
[INFO] [talledLocalContainer]java.lang.IllegalArgumentException: Document doesn't exist at '/content/documents/xxx'.
[INFO] [talledLocalContainer] at org.onehippo.forge.content.exim.core.impl.WorkflowDocumentManagerImpl.obtainEditableDocument(WorkflowDocumentManagerImpl.java:397)
[INFO] [talledLocalContainer] at org.onehippo.forge.content.exim.core.impl.WorkflowDocumentVariantImportTask.updateDocumentFromVariantContentNode(WorkflowDocumentVariantImportTask.java:130)
[INFO] [talledLocalContainer] at org.onehippo.forge.content.exim.core.impl.WorkflowDocumentVariantImportTask.createOrUpdateDocumentFromVariantContentNode(WorkflowDocumentVariantImportTask.java:88)
[INFO] [talledLocalContainer] at org.onehippo.forge.content.exim.core.DocumentVariantImportTask$createOrUpdateDocumentFromVariantContentNode.call(Unknown Source)

It turned out that it was simply caused by the folder under a hippostd:directory.

Thanks to bsnijders, the root cause was found:

Nailed the issue. Apparently in org.onehippo.forge.content.exim.core.util.HippoNodeUtils#getChildNodeOfType the current node is checked against a list of allowed childNodeTypes (given as a parameter to this method). In my case it turned out to be that /content/documents/.../.../... consisted of an unallowed intermediate jcr:primaryType. The getChildNodeOfType performs a check on the given childNodeTypes "hippostd:folder". Given my structure:
/ = rep:root, as starting point not validated
/content = hippostd:folder, passing validation
/content/documents = hippostd:directory, not passing validation, breaking the entire import process

So, I've fixed it by altering the primaryType of the documents folder from hippostd:directory to hippostd:folder. Now it works.

In my opinion, it might be good to investigate whether hippostd:directory is actually valid in that spot from the product's point of view

• if it's allowed there, the ExIm module should guard against this
• if it's not allowed there, it might be a good idea to have ExIm provide some more meaningful logging on failing nodeType validations

Furthermore, the fact that the entire process breaks down illustrates the case why exact root cause analysis should be provided i.e. by means of logging. Now it was easy to check, given that I test with three documents. But my production set is somewhere close to 60K documents , preventing manual inspection.

As every content related folder is being created as hippostd:folder since at least v10, it is not sure that we have to allow an interim hippostd:directory folders...

But, it is a valid point at least that we should give a clearer exception or logging when there's an unexpected interim directory in this case.