If the client sends another query before reading the previous result, it
was possible that another session finished the shard update and the
following query would reuse this result. This would cause the assertion in
the delayed call to fail as it assumes the shard would always be empty
when it was being called. To correctly handle this case, the delayed call
must be the one that moves the session into the normal routing state.