If two futures f1 and f2 depend on each other, then we want f2 to fail when f1 raised and exception. This is currently handled by executorlib internally, without evaluating the function related to the second future f2.
For batched futures the case is not so simple. One option would be to move the failed futures to the end of the execution. But for the case when all futures fail, this would require all futures to be evaluated before the workflow breaks down. An alternative would be to return failed futures just like successful futures, as both of them are done.
Maybe the easiest way is for the user to decide by adding another parameter to the batched() function.
If two futures
f1andf2depend on each other, then we wantf2to fail whenf1raised and exception. This is currently handled by executorlib internally, without evaluating the function related to the second futuref2.For batched futures the case is not so simple. One option would be to move the failed futures to the end of the execution. But for the case when all futures fail, this would require all futures to be evaluated before the workflow breaks down. An alternative would be to return failed futures just like successful futures, as both of them are done.
Maybe the easiest way is for the user to decide by adding another parameter to the
batched()function.