You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if async_tasks.is_empty() && retries_remaining == 0{
return last_error.unwrap_or({
Err(EMPTY_PLAN_ERROR)
});
}
}
There is a small issue with this code. If fiber returns None (i.e., plan is exhausted) there still may be some remaining retries. The driver will wait for remaining retries. It is expected behaviour for most scenarios - there may be some other fibers still running, thus we do not return from this function prematurely. However, we could safely return from the function if both of the following conditions are met:
fiber returns None -> plan is empty/exhausted
there are no other running fibers in the meantime. If there are some, we should wait for their completion.
Second condition could be checked by introducing additional variable that keeps track of number of currently running fibers. From our experience, speculative_execution::execute's logic seems to be error-prone. This is why, in addition to the change mentioned in the issue, we should think of a way to rewrite the logic in a safer manner.
The text was updated successfully, but these errors were encountered:
This issue is related to
speculative_execution::execute
function - especially this part in current version of the driver:scylla-rust-driver/scylla/src/policies/speculative_execution.rs
Lines 201 to 214 in 4a9367c
There is a small issue with this code. If fiber returns
None
(i.e., plan is exhausted) there still may be some remaining retries. The driver will wait for remaining retries. It is expected behaviour for most scenarios - there may be some other fibers still running, thus we do not return from this function prematurely. However, we could safely return from the function if both of the following conditions are met:None
-> plan is empty/exhaustedSecond condition could be checked by introducing additional variable that keeps track of number of currently running fibers. From our experience,
speculative_execution::execute
's logic seems to be error-prone. This is why, in addition to the change mentioned in the issue, we should think of a way to rewrite the logic in a safer manner.The text was updated successfully, but these errors were encountered: