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.