Ted Blackman 155ab60609 ford: dequeue orphans ... @ixv recently uncovered a bug (#2180) in Ford that caused certain rebuilds to crash. @Fang- and I believe this change should fix the bug, and we have confirmed that the reproduction that used to fail about two thirds of the time now has not failed at all in the ten or so times we've run it since then. @Fang- is still running more tests to confirm the fix with more certainty. It turned out the cause was that (depending on the rebuild order, which is unspecified and should not need to be specified), Ford could enqueue a provisional sub-build to be run but then, later in the same +gather call, discover that the sub-build was in fact an orphan and delete it from builds.state accordingly. Then when Ford tried to run the sub-build, it would have already been deleted from the state, so Ford would crash when trying to process its result in +reduce. The fix was to make sure that when we discover a provisional sub-build is orphaned, dequeue it from candidate-builds and next-builds to make sure we don't try to run it. I'm about 95% sure this fix completely solves the bug.		2020-01-28 17:29:24 +04:00
..
vane	ford: dequeue orphans	2020-01-28 17:29:24 +04:00
arvo.hoon	arvo: remove unneeded top-level mock	2019-12-02 20:52:59 -08:00
hoon.hoon	various: use =/ in place of =+ ^-	2019-12-21 14:29:14 -03:30
zuse.hoon	gall: (list path) in %fact and %kick	2019-12-23 13:37:32 +01:00