The parameter known as maxIterations is responsible for deciding when a traversal should automatically stop after a certain number of iterations. This feature is put in place to prevent you from endlessly looping through a cyclic graph during a traversal.
It's important to note that the maxIterations does not dictate the depth of the traversal, but rather sets a limit on the number of vertices that can be visited before an error is thrown and the traversal stops.
For those wondering how to determine an appropriate maximum value for maxIterations, consider this example: Starting at a specified vertex initiates the first iteration. From there, any outgoing or ingoing connections are identified. If, for instance, there are five connections to explore from the initial vertex, you would need a minimum of 6 for maxIterations (1 for the start vertex plus 5 for the next round). If each of these 5 vertices also has 5 connections, you'd require at least 25 more iterations, bringing the total required maxIterations to 31. As you move to subsequent levels with 5 connections each, the needed iterations increase by multiples of 5.
This demonstrates that simply applying a constant increment to the maxIterations won't suffice, given the non-linear nature of the series observed (1, 6, 31, 156). The number of iterations necessary depends heavily on the data structure and connectivity between vertices.
If your goal is solely to restrict the traversal depth, utilize the minDepth or
maxDepth</code parameters while setting <code>maxIterations
to a high value unlikely to be reached due to the bounds set by
maxDepth. Additional options like
direction (using
any yields more results at the risk of encountering cycles; opt for
inbound or
outbound</code whenever possible) and <code>uniqueness
(determines how often a specific vertex or connecting edge is visited) can also help control the volume of data extracted during a traversal.