@Override
  public void onResponse(ReplicaId replicaId, TrackedRequestFinalState trackedRequestFinalState) {
    inflightCount--;
    // once a response has been received, a replica is no longer in the pool or currently in flight.
    modifyReplicasInPoolOrInFlightCount(-1);
    switch (trackedRequestFinalState) {
      case SUCCESS:
        successReplica.add(replicaId);
        replicaSuccessCount++;
        break;
      // Request disabled may happen when PUT/DELETE/TTLUpdate requests attempt to perform on replicas that are being
      // decommissioned (i.e STANDBY -> INACTIVE). This is because decommission may take some time and frontends still
      // hold old view. Aforementioned requests are rejected by server with Temporarily_Disabled error. For DELETE/TTLUpdate,
      // even though we may receive such errors, the success target is still same(=2). For PUT, we have to adjust the
      // success target (quorum) to let some PUT operations (with at least 2 requests succeeded on new replicas) succeed.
      // Currently, disabledCount only applies to PUT operation.
      case REQUEST_DISABLED:
        disabledCount++;
        break;
      default:
        failedCount++;
        // NOT_FOUND is a special error. When tracker sees >= numReplicasInOriginatingDc - 1 "NOT_FOUND" from the
        // originating DC, we can be sure the operation will end up with a NOT_FOUND error.
        if (trackedRequestFinalState == TrackedRequestFinalState.NOT_FOUND) {
          totalNotFoundCount++;
          if (replicaId.getDataNodeId().getDatacenterName().equals(originatingDcName)) {
            if (originatingDcLeaderOrStandbyReplicas.contains(replicaId)) {
              // Since bootstrap replicas could still be catching up, treat NotFound responses only from leader or
              // standby replicas as valid.
              originatingDcNotFoundCount++;
            }
          }
        }
    }
  }
The dynamic success target is introduced mainly for following use case:
In the intermediate state of "move replica", when decommission of old replicas is initiated(but hasn't transited to
INACTIVE yet), the PUT requests should be rejected on old replicas. For frontends, they are seeing both old and new
replicas(lets say 3 old and 3 new) and the success target should be 6 - 1 = 5. In the aforementioned scenario, PUT
request failed on 3 old replicas. It seems we should fail whole PUT operation because number of remaining requests
is already less than success target.
From another point of view, however, PUT request is highly likely to succeed on 3 new replicas and we actually
could consider it success without generating "slip put" (which makes PUT latency worse). The reason is, if new PUTs
already succeeded on at least 2 new replicas,  read-after-write should always succeed because frontends are always
able to see new replicas and subsequent READ/DELETE/TtlUpdate request should succeed on at least 2 aforementioned
new replicas.
ambry-router/src/main/java/com/github/ambry/router/SimpleOperationTracker.java