Please retry again, server is not ready to accept requests

Error message

Please retry again, server is not ready to accept requests

What it means

errHealth is a package-level sentinel error returned while the server's healthCheck flag is not set, i.e. the server has not finished initializing (or is shutting down) and cannot accept requests. HealthCheck returns it and client-facing entry points (such as NewMinioClient setup paths that gate on health) surface it so callers know to retry rather than treat the operation as failed permanently.

Source

Thrown at x/health.go:23

package x

import (
	"sync/atomic"

	"github.com/golang/glog"
	"github.com/pkg/errors"
)

var (
	// the drainingMode variable should be accessed through the atomic.Store and atomic.Load
	// functions. The value 0 means the draining-mode is disabled, and the value 1 means the
	// mode is enabled
	drainingMode              uint32
	extSnapshotStreamingState uint32

	healthCheck     uint32
	errHealth       = errors.New("Please retry again, server is not ready to accept requests")
	errDrainingMode = errors.New("the server is in draining mode " +
		"and client requests will only be allowed after exiting the mode " +
		" by sending a GraphQL draining(enable: false) mutation to /admin")
)

// UpdateHealthStatus updates the server's health status so it can start accepting requests.
func UpdateHealthStatus(ok bool) {
	setStatus(&healthCheck, ok)
}

// UpdateDrainingMode updates the server's draining mode
func UpdateDrainingMode(enable bool) {
	setStatus(&drainingMode, enable)
}

// ExtSnapshotStreamingState updates the server's import mode
func ExtSnapshotStreamingState(enable bool) {
	glog.Info("[import] Updating import mode to ", enable)

View on GitHub (pinned to 759e242be6)

Solutions

Wait for the server to finish startup and begin accepting requests (health endpoint returns OK) before sending requests
Retry the request with exponential backoff — this error is explicitly transient
Check server logs for why startup is stalled (bad config, pending Raft connection, slow WAL replay)
Fix readiness probes so traffic is only routed once UpdateHealthStatus(true) ran

Example fix

// before
client := NewMinioClient(...) // returns errHealth right after alpha start
// after
for i := 0; i < 30; i++ {
    if err := HealthCheck(); err == nil {
        break
    }
    time.Sleep(2 * time.Second) // retry until server is ready
}
client := NewMinioClient(...)

Defensive patterns

Strategy: retry

Validate before calling

// Gate work on the health endpoint before issuing requests
if err := x.HealthCheck(); err != nil {
    // server not ready yet — defer/start retry loop
}

Try / catch

err := doRequest(client)
if err != nil && strings.Contains(err.Error(), "server is not ready") {
    time.Sleep(backoff) // exponential backoff, bounded retries
    err = doRequest(client)
}

Prevention

Add readiness probes that only route traffic once the server reports healthy
Start clients only after the alpha's health endpoint returns OK
Use bounded exponential-backoff retries for this explicitly transient error
Watch startup logs to distinguish 'still starting' from a wedged startup

When it happens

Trigger: Sending a request before UpdateHealthStatus(true) has been called after alpha startup; probing HealthCheck during initialization, config load, or drain shutdown; calling NewMinioClient before the server is ready.

Common situations: Load balancers / health probes hitting an alpha seconds after start; orchestration (Kubernetes) starting clients before the server is ready; requests during a restart window.

Related errors

AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/32dae0cb5f4dd657. Report an issue: GitHub.