OnFollowerCheckRequest current term is – How to solve this Elasticsearch exception

Opster Team

August-23, Version: 7-7.15

Before you dig into reading this guide, have you tried asking OpsGPT what this log means? You’ll receive a customized analysis of your log.

Try OpsGPT now for step-by-step guidance and tailored insights into your Elasticsearch operation.

Briefly, this error occurs when there is a discrepancy in the term numbers between the leader and follower nodes in an Elasticsearch cluster. This can happen due to network issues, node failures, or incorrect configurations. To resolve this issue, you can try the following: 1) Check and fix any network connectivity issues. 2) Ensure all nodes are running the same version of Elasticsearch. 3) Check the cluster’s health and restart any failed nodes. 4) Review and correct any incorrect configurations in the Elasticsearch.yml file.

For a complete solution to your to your search operation, try for free AutoOps for Elasticsearch & OpenSearch . With AutoOps and Opster’s proactive support, you don’t have to worry about your search operation – we take charge of it. Get improved performance & stability with less hardware.

This guide will help you check for common problems that cause the log ” onFollowerCheckRequest: current term is [ ” to appear. To understand the issues related to this log, read the explanation below about the following Elasticsearch concepts: cluster.

Log Context

Log “onFollowerCheckRequest: current term is [” class name is Coordinator.java. We extracted the following from Elasticsearch source code for those seeking an in-depth context :

 synchronized (mutex) {
 ensureTermAtLeast(followerCheckRequest.getSender(); followerCheckRequest.getTerm());  if (getCurrentTerm() != followerCheckRequest.getTerm()) {
 logger.trace("onFollowerCheckRequest: current term is [{}]; rejecting {}"; getCurrentTerm(); followerCheckRequest);
 throw new CoordinationStateRejectedException("onFollowerCheckRequest: current term is ["
 + getCurrentTerm() + "]; rejecting " + followerCheckRequest);
 }  // check if node has accepted a state in this term already. If not; this node has never committed a cluster state in this
 // term and therefore never removed the NO_MASTER_BLOCK for this term. This logic ensures that we quickly turn a node


How helpful was this guide?

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?