scout message goes off the loop

[michielbdejong]

this happens from fixture-30k, and seems related to our new pickIncarnation function which was introduced in #15.

[michielbdejong]

Error: 1168 picked 2471 who is not on the loop

{"command":"scout","probeId":"6","maxIncarnation":585,"amount":4500,"debugInfo":{"loop":["1","5","1168","4982","1"]}}

"in":{"5":0,"2471":565} "out":{"26":0,"422":566,"423":575,"983":576,"984":577,"988":578,"989":579,"1690":580,"1706":581,"3441":582,"3442":583,"3451":584,"4982":585} "loops":{}}

[michielbdejong]

found loop (6:585) [] [ '1', '5', '1168', '4982', '1' ]

[michielbdejong]

Hm:

found loop (6:0) [ '1',    '5', '1168', '26', '984',  '423','1699'] [ '227', '228', '3907', '227' ]
[...]
found loop (6:565) [ '1', '5' ] [ '1168', '26', '2471', '1168' ]
backtracked (6:566) [ '1', '5', '1168', '422' ] [ '983' ]
[...]
found loop (6:585) [] [ '1', '5', '1168', '4982', '1' ]

So 5->1168 happens on incarnation 0, in incarnation 565 a loop is found that includes 1168 but not 5, but this loop does not exhaust the outgoing options of node 1168, so the probe continues. And then in 585, a loop is found that does include both 5 and 1168, and then the remnants of loop 565 get in the way.

We could try to mitigate this by cleaning up the remnants of loop 565 when it gets scouted, but there is no guarantee that loop 565 gets scouted before loop 585 does, so that wouldn't work. Hm...

[michielbdejong]

In this case, it's the "looper move" 2471 -> 1168 (the one that closes the loop for (6:565)) that gets in the way. We could also imagine that something like this happened

found loop (6:580) [] [ '1', '5', '1168', '26', '4982', '1' ]

But then node 26 would not get confused because it would still just have incoming 1168 on incarnation 0. It's really just the "looper move" that messes it up, right?