Good idea, so you mean we should immediately when having the blinded path check if we can build the whole route before exiting the route search, so we make sure the returned routes are also possible to use ?

@ziggie1984 - yeah, or we make a way for the logic that is doing the iterating and building to query like NextCandidateRoute or something like that. Or actually, perhaps should return all possible routes and then do the MaxPath cap later on instead of as early as it is currently done

Do you mean that it might return less than MaxNumPaths routes without exhausting all valid routes? Maybe I can help to fix it!

@MPins - im saying it currently does the following:

1. Chooses MaxNumPaths candidate paths
2. Passes that to BuildBlindedPaths which might drop some of the paths returned cause they turn out not to be valid.

This is not ideal cause we then we can easily run out of paths to try.

Instead, the MaxNumPaths restriction should be applied later on instead. So when selecting candidates, we should not limit at that point.

Got it. If nobody had started working on it, I can give a try.

This is for my education...why do we have a limit capped by MaxNumPaths?

otherwise the invoice would become super huge, there might be a huge number of paths to a particular node. Moreover we select the paths with the most probability at first so further paths have an even lower chance to succeed in making the payment so it makes sense to limit this number from this pov as well.