code: private CompletableFuture<OperationResult> applyQuery(Indexed<QueryEntry> entry) {
      RaftSession session = raft.getSessions().getSession(entry.entry().session());
  
      // If the session is null then that indicates that the session already timed out or it never existed.
      // Return with an UnknownSessionException.
      if (session == null) {
        logger.warn("Unknown session: " + entry.entry().session());
        return Futures.exceptionalFuture(new RaftException.UnknownSession("unknown session " + entry.entry().session()));
      }
  
      // Execute the query using the state machine associated with the session.
      return session.getService()
          .executeQuery(
              entry.index(),
              entry.entry().sequenceNumber(),
              entry.entry().timestamp(),
              session,
              entry.entry().operation());
    }
docs: Applies a query entry to the state machine.
  <p>
  Query entries are applied to the user {@link PrimitiveService} for read-only operations. Because queries are
  read-only, they may only be applied on a single server in the cluster, and query entries do not go through the Raft
  log. Thus, it is critical that measures be taken to ensure clients see a consistent view of the cluster event when
  switching servers. To do so, clients provide a sequence and version number for each query. The sequence number is
  the order in which the query was sent by the client. Sequence numbers are shared across both commands and queries.
  The version number indicates the last index for which the client saw a command or query response. In the event that
  the lastApplied index of this state machine does not meet the provided version number, we wait for the state
  machine to catch up before applying the query. This ensures clients see state progress monotonically even when
  switching servers.
  <p>
  Because queries may only be applied on a single server in the cluster they cannot result in the publishing of
  session events. Events require commands to be written to the Raft log to ensure fault-tolerance and consistency
  across the cluster.