MultiTargetPath overwrites input array with strange results

I have the following method:

IEnumerator WalkAfterFrame(){
	yield return new WaitForEndOfFrame ();
	float delay = Random.Range (0.5f, 2.5f);
	Vector3[] exitPoints = new Vector3[GameMngr.officeGenerator.exits.Count];
	for (int i = 0; i < GameMngr.officeGenerator.exits.Count; i++) {
		exitPoints [i] = GameMngr.officeGenerator.exits [i].transform.position;
	}
	//seek towards all exits and get to the closest one it can reach.
	yield return new WaitForSeconds (delay);
	while (true) {
		if(currentPath == null){
			seeker.StartMultiTargetPath (transform.position, exitPoints.Clone () as Vector3[], false);
		}
		yield return new WaitForSeconds (2f);
	}
}

The issue lies in the exitPoints.Clone() in the StartMultiTargetPath argument. After a few hours of debugging i figured out that StartMultiTargetPath overwrites the content of the array within the method. Resulting in my little loop getting all messed up.
It happens when you put an array of end points into the method, of which 1 or more do not find a correct path to the end point. When that happens the vecto3 is overwriten with what seems to be the new endpoint to which it will be walking. Which is neat, but very unexpected.

I think the culprit is on MultiTargetPath.cs:359. targetPoints[i] = endNNinfo.clampedPosition;
And to prevent it from happening either it must never be set, or the MultiTargetPath.Setup() method should clone the array at all times or something similar.

Thanks for hearing me out,
Vince

Hm, ok, might be a good idea to change that. It’s not particularly obvious that it does it.
When I wrote it the first time I likely did that for performance reasons, but it is likely not worth it for the bugs it can introduce. The target array is usually small anyway.

Indeed. A clone of the array is not that horrible for performance/RAM. If you have an input of over 100 targets for this method i suppose you have other bottlenecks to worry about at that point.