Stefan Egli created OAK-11806:
---------------------------------
Summary: bundled child can mix up properties with similarly named
sibling
Key: OAK-11806
URL: https://issues.apache.org/jira/browse/OAK-11806
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk
Reporter: Stefan Egli
In DocumentNodeStore, consider a bundled document that has a structure like so:
{noformat}
'child/:doc-self-path': { 'r123456789a-0-1': '"child"' },
'child/jcr:primaryType': { 'r123456789a-0-1': '"nam:nt:unstructured"' },
'child/propertyA': { 'r123456789a-0-1': '"child-value"' },
..
'child2/:doc-self-path': { 'r12345678b1-0-2': '"child2"' },
'child2/jcr:primaryType': { 'r12345678b1-0-2': '"nam:nt:unstructured"' },
'child2/propertyA': { 'r12345678b1-0-2': '"child2-value"' },
..
'child11/:doc-self-path': { 'r12345678c3-0-3': '"child11"' },
'child11/jcr:primaryType': { 'r12345678c3-0-3': '"nam:nt:unstructured"' },
'child11/propertyA': { 'r12345678c3-0-3': '"child11-value"' },
..
{noformat}
In such a bundling case resolving the document into NodeStates (eg via
{{getChildNodeEntries}} or anything similar for that matter) goes via
*
[bundlingContext.getProperties()|https://github.com/apache/jackrabbit-oak/blob/9ef53aabcf54d5d6a3879f1d88b3f05d61875b9f/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeState.java#L130]
* which then [calls
BundlorUtils.getMatchingProperties()|https://github.com/apache/jackrabbit-oak/blob/9ef53aabcf54d5d6a3879f1d88b3f05d61875b9f/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeState.java#L802].
* In BundlorUtils, it goes through all properties existing on the bundled
documents (that is : all bundled properties of all bundled children) - in more
or less undefined order.
** as part of that it check if a given property [starts
with|https://github.com/apache/jackrabbit-oak/blob/7b252c2702cb0b9494e0dc3e23c00b5e1313fed2/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/bundlor/BundlorUtils.java#L55]
the {{matchedPath}}.
** that matchedPath in case of doing this for "child" is .. "child".
** so if it resolves "child" it will match any property that starts with ...
"child"
** which will unfortunately also include properties from "child2" or "child11"
etc.
** the result is that it will more or less randomly contain properties of
siblings that start with the same name
In other words: resolving properties of bundled child A "randomly" includes
properties of siblings that also start with A.
The "randomness" is given by the fact that HashMap (which is what is passed to
getMatchingProperties) does not guarantee a stable iteration order. In
particular two JVM incarnations iterating over the same Map might likely not
see the same order. This leads to the mixed-up properties being seemingly
random - as it depends on the order in which the map is iterated over.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
