fix(core): Add maxfrontiersize to shortest path query

[harshil-goel]

Currently we use dijkstra's algorithm to find shortest path. Sometimes the heap could grow indefinitely, which would slow down the query significantly and cause dgraph to go out of memory. This would only happen in very specific instances depending upon the graph. To fix this, we are introducing a new argument, maxfrontiersize in shortest path query. This would limit the size of the heap fixing the issue.
New query would look like:

{ 
  path as shortest(from: 0x2, to: 0x5, numpaths:5, maxfrontiersize: 10000) {
  connected_to
    @facets(weight)
 }

Fixes: #9333

[mangalaman93]

Please add a test for this change

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[matthewmcneely]

@harshil-goel Is "heap" the best term for this? Is it the max number of nodes to be considered? Maybe "maxnodes"?

[harshil-goel]

@mangalaman93 @matthewmcneely What term do you think works well:
maxFrontierSize - "Frontier" is a common term in graph search for the set of nodes to be explored next
pathExplorationLimit - Describes the purpose rather than the implementation
maxCandidatePaths - Indicates you're limiting the number of candidate paths under consideration

[matthewmcneely]

I like "frontier size", that lines up nicely with terminology that I've encountered over the years.