Node traversal exception in upgrade to 6.5.21

[ASP_Corp]

Hi, we just upgraded to 6.5.21 and we see that when we try to delete any page from the sites, we get the dreaded Red "error" popup. error logs throw the following error 

org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught Throwable org.apache.jackrabbit.oak.query.RuntimeNodeTraversalException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.

any help?

when i compare /oak:index with the old non-upgraded instance i see that there are 4 new indexes being added AssetPrefixNodeName, CqAuditEvent, GraphQlConfig, fragments. when i try to package the /oak:index in the 6.5.21 instance i get the following error "Unable to retrieve primary type for Node /oak:index/cq:AuditEvent" any help?

[Ekhlaque]

@ASP_Corp ,I would suggest identifying the query causing the traversal exception and optimising it.Use specific paths in queries to limit the number of nodes being traversed. using isdescendantnode('/content') instead of broad node queries.

[ASP_Corp]

Hi @Ekhlaque , thank you for the reply, but i can't edit the query because the deletion of assets is a basic query inbuilt in AEM, maybe iam wrong?.

[giuseppebag]

IMHO, you need to determine if any of your queries could be causing the issue.

Here’s a concise list of actions to enhance the performance of Oak queries by reducing node traversal:

• Create custom Oak indexes tailored to high-use queries to avoid full repository scans.
• Narrow search scope using path constraints in JCR-SQL2 or XPath.
• Limit traversal to specific subtrees (e.g., /content/dam) instead of querying / to minimize scanned nodes.
• Include jcr:primaryType or jcr:mixinTypes in query predicates early to discard irrelevant nodes upfront, reducing intermediate results.
• Use property-based filters (=, >, etc.) instead of jcr:contains for non-text properties, as full-text queries trigger costly Lucene index scans.
• Use LIMIT and OFFSET to retrieve small batches of data. Avoid unbounded queries that traverse excessive nodes to fetch large datasets.
• Ensure indexes include propertyNames, type, and async settings. Use evaluatePathRestrictions=true for path-filtered queries to skip irrelevant subtrees.
• Structure queries to use a single index. Cross-joins (multiple unrelated conditions) force Oak to scan all node combinations, increasing traversal.
• Replace LIKE '%text%' with exact matches (property=value) where possible. Wildcards often bypass indexes and scan all nodes.
• Remove ORDER BY clauses unless required. Sorting large result sets forces Oak to traverse and buffer all nodes before returning data.

Further references:

• Query and Indexing Best Practices
• Best Practices for Queries and Indexing
• Troubleshooting Slow Queries
• Analyzing AEM Indexing Issues

[ASP_Corp]

thank you for the reply, but when you are deleting an asset, the query generated behind the scenes is not a query i wrote, it is an inbuilt query run the AEM OOTB functionality. If the query is what i wrote i can modify, but in this issue, that is not the case. Morover this issue is observed after migration to 6.5.21 upgrade. 

[giuseppebag · Accepted solution]

Please ensure that you disable any Launchers found at (/libs/cq/workflow/admin/console/content/launchers.html) that are triggering your workflows. Additionally, if you have customized any out-of-the-box (OOTB) workflows by adding steps that execute your code, please restore them to their original versions. We want to rule out the possibility that any of your code could be causing the issue.

If you’ve already confirmed that your code isn’t the issue, have you found any clues regarding which part of the AEM code might be causing the problem? If so, I recommend reaching out to Adobe Support for further investigation.

[ASP_Corp]

Iam picking this as the correct reply as this gave me some directions to look for, but our issue was not resolved and we reached out to Adobe support.

[kautuk_sahni]

@ASP_Corp Did you find the suggestions helpful? Please let us know if you need more information. If a response worked, kindly mark it as correct for posterity; alternatively, if you found a solution yourself, we’d appreciate it if you could share it with the community. Thank you!