Apply future deadlocks if quorum cannot be reached

[tylertreat]

I believe this is a duplicate of #145 which was closed due to no activity but appears to be unresolved.

I have calls to Apply which sometimes occur at the same time as nodes in the cluster being stopped, e.g. in unit/integration tests. In this situation, waiting on the result from the future returned by Apply (deferError.Error()) will block forever, causing the test to deadlock. This is because deferError is waiting on a response from the errCh which is never going to come.

Interestingly, a change was added a while back to add a ShutdownCh to deferError to allow futures to react to shutdowns. However, this appears to only be used to address a deadlock that occurred when snapshots are taken.

It seems to me like deferError ought to have a timeout on it, either taking its own timeout on calls to Error() or by respecting the timeout passed to Apply(). Given that the future returned by Apply involves RPCs and consensus, it seems like this should have a timeout to prevent potential deadlock situations.

[stale]

Hey there,
We wanted to check in on this request since it has been inactive for at least 90 days.
Have you reviewed the latest godocs?
If you think this is still an important issue in the latest version of the Raft library or
its documentation please feel let us know and we'll keep it open for investigation.
If there is still no activity on this request in 30 days, we will go ahead and close it.
Thank you!

[tylertreat]

Please keep this open.

[b0nd21]

Right now (February 2025) the issue still persists. Found that yesterday on the latest version of the library. Error case: used Apply future with Error() blocking call, then if cluster is changed while the action (for example, leader changed), error doesn’t return even after ApplyTimeout (but seems like it should be something like ErrLeaderChanged) and the function deadlocks never returning the future.