Slow Path Decide Bug?
The TAPIR paper says
Otherwise, the client takes the slow path: once it receives
f + 1
responses (retrying if necessary), then it sends<FINALIZE, id, result>
to all replicas, where result is obtained from executing the decide function.
Inside of IRClient::ConsensusSlowPath
, the client is not waiting for f + 1
responses before calling decide and sending the result back to the replicas (see here). I wasn't sure if this was a bug or an optimization that was omitted from the TAPIR paper.