ReplicaStatus getReplicaStatus(RemoteReplicaInfo remoteReplicaInfo) {
    ReplicaId replicaId = remoteReplicaInfo.getReplicaId();
    boolean inBackoff = time.milliseconds() < remoteReplicaInfo.getReEnableReplicationTime();
    if (replicaId.isDown() || inBackoff || remoteReplicaInfo.getLocalStore().getCurrentState() == ReplicaState.OFFLINE
        || replicationDisabledPartitions.contains(replicaId.getPartitionId())) {

      if (replicationConfig.replicationEnableInfoLogsForSkippedPartitions) {
        logger.info(
            "Skipping replication on replica {} because one of following conditions is true: remote replica is down "
                + "= {}; in backoff = {}; local store is offline = {}; replication is disabled = {}.",
            replicaId.getPartitionId().toPathString(), replicaId.isDown(), inBackoff,
            remoteReplicaInfo.getLocalStore().getCurrentState() == ReplicaState.OFFLINE,
            replicationDisabledPartitions.contains(replicaId.getPartitionId()));
      } else {
        logger.trace(
            "Skipping replication on replica {} because one of following conditions is true: remote replica is down "
                + "= {}; in backoff = {}; local store is offline = {}; replication is disabled = {}.",
            replicaId.getPartitionId().toPathString(), replicaId.isDown(), inBackoff,
            remoteReplicaInfo.getLocalStore().getCurrentState() == ReplicaState.OFFLINE,
            replicationDisabledPartitions.contains(replicaId.getPartitionId()));
      }

      return ReplicaStatus.OFFLINE;
    }

    if (replicatingFromRemoteColo && leaderBasedReplicationAdmin != null) {
      // check if all missing keys for standby replicas from previous replication cycle are now obtained
      // via leader replica. If we still have missing keys, don't include them in current replication cycle
      // to avoid sending duplicate metadata requests since their token wouldn't have advanced.
      processMissingKeysFromPreviousMetadataResponse(remoteReplicaInfo);
      if (containsMissingKeysFromPreviousMetadataExchange(remoteReplicaInfo)) {

        // Use case: In leader-based cross colo replication, non-leader replica pairs don't fetch blobs for missing keys
        // found in metadata exchange and expect them to come from leader<->leader replication and intra-dc replication.
        // However, if for any reason, some of their missing blobs never arrive via local leader, this is a safety feature
        // for standbys to fetch the blobs themselves in order to avoid being stuck.

        // Example scenario: For DELETE after PUT use case in remote data center, it is possible that standby replicas get
        // only PUT record in its replication cycle (DELETE record will come in next cycle) while leader gets both
        // PUT and DELETE together in its replication cycle. Due to that, deleted blob is not fetched by leader and is not
        // replicated from leader to standby. As a result, the corresponding PUT record in standby's missing blobs set is
        // never received.

        // Time out period is configurable via replicationStandbyWaitTimeoutToTriggerCrossColoFetchSeconds. If
        // replicationStandbyWaitTimeoutToTriggerCrossColoFetchSeconds == -1, this safety feature is disabled.

        if (replicationConfig.replicationStandbyWaitTimeoutToTriggerCrossColoFetchSeconds != -1) {
          ReplicaId localReplica = remoteReplicaInfo.getLocalReplicaId();
          ReplicaId remoteReplica = remoteReplicaInfo.getReplicaId();
          ExchangeMetadataResponse exchangeMetadataResponse = remoteReplicaInfo.getExchangeMetadataResponse();
          if (!leaderBasedReplicationAdmin.isLeaderPair(localReplica, remoteReplica)
              && exchangeMetadataResponse.hasMissingStoreMessages()
              && (time.seconds() - exchangeMetadataResponse.lastMissingMessageReceivedTimeSec)
              > replicationConfig.replicationStandbyWaitTimeoutToTriggerCrossColoFetchSeconds) {
            return ReplicaStatus.STANDBY_TIMED_OUT_ON_NO_PROGRESS;
          }
        }
        return ReplicaStatus.STANDBY;
      }
    }
    return ReplicaStatus.ACTIVE;
  }
performs below checks and gives status of replica

1. check if replica is OFFLINE then return OFFLINE status

2. check these conditions
   1. check if we are doing cross colo replication
   2. check if leader based replication is enabled
   3. our local replica is not leader
   4. we have missing blobs from last ReplicaMetadataRequest
   return STANDBY_TIMED_OUT_ON_NO_PROGRESS if last missing blob arrived  before replicationConfig.replicationStandbyWaitTimeoutToTriggerCrossColoFetchSeconds
   return STANDBY otherwise as we need to wait for data to come through intra colo replication

3. return ACTIVE status if above criteria are not met

 We can pull data only from ACTIVE replicas and STANDBY_TIMED_OUT_ON_NO_PROGRESS replicas
ambry-replication/src/main/java/com/github/ambry/replication/ReplicaThread.java