What causes "failed to create Elasticsearch client: %w" in jaegertracing/jaeger?

Read the wrapped underlying error and address it directly (DNS, refused, 401, x509).

failed to create Elasticsearch client

Error message

failed to create Elasticsearch client: %w

What it means

After the config loads, ExecuteAction creates an Elasticsearch client via newESClient; any failure is wrapped as "failed to create Elasticsearch client". Like error 130, the root cause is preserved via %w — typically the ES endpoint is unreachable, unauthenticated, or the client setup (TLS, version discovery) failed.

Solutions

Read the wrapped underlying error and address it directly (DNS, refused, 401, x509).
Confirm ES_URL connectivity with curl from the same environment.
Supply correct TLS/auth flags for secured Elasticsearch/OpenSearch.
Ensure ordering: run init after ES is healthy (readiness gate, retry).

Example fix

// before
./es-rollover init http://localhost:9200   # ES not on localhost
// after
./es-rollover init http://elasticsearch.default.svc:9200

Defensive patterns

Strategy: retry

Validate before calling

resp, err := http.Get(esURL + "/_cluster/health")
if err != nil || resp.StatusCode != 200 {
    return fmt.Errorf("ES not ready at %s", esURL)
}
resp.Body.Close()

Try / catch

err := ExecuteAction(opts, createAction)
for retries := 0; err != nil && errors.Is(err, errTransient) && retries < 3; retries++ {
    time.Sleep(backoff)
    err = ExecuteAction(opts, createAction)
}

Prevention

Gate rollover jobs on ES cluster-health readiness.
Centralize the ES URL in one config source to avoid typos.
Provide TLS material (ca/token) as mounted secrets, not inline flags.
Read the %w-wrapped cause first when debugging.

When it happens

Trigger: Running any es-rollover action (init, rollover, lookback) when the Elasticsearch host in the first argument cannot be connected to, TLS handshake fails, or credentials are rejected during client construction.

Common situations: ES still starting when the rollover cronjob fires; wrong ES_URL; missing ca cert or bearer token for a secured cluster; network policy blocking pod-to-ES traffic.

Related errors

AI-assisted analysis of jaegertracing/jaeger@806f444784 (2026-09-01). Data as JSON: /api/errors/9f8341a07a4002d3. Report an issue: GitHub.

Appendix: source

Thrown at cmd/es-rollover/app/actions.go:74

type ActionExecuteOptions struct {
	Args   []string
	Viper  *viper.Viper
	Logger *zap.Logger
}

// ActionCreatorFunction type is the function type in charge of create the action to be executed
type ActionCreatorFunction func(*esclient.Client, Config) Action

// ExecuteAction execute the action returned by the createAction function
func ExecuteAction(opts ActionExecuteOptions, createAction ActionCreatorFunction) error {
	cfg := Config{}
	if err := cfg.InitFromViper(opts.Viper); err != nil {
		return fmt.Errorf("failed to initialize config: %w", err)
	}

	esClient, err := newESClient(context.Background(), opts.Args[0], &cfg, opts.Logger)
	if err != nil {
		return fmt.Errorf("failed to create Elasticsearch client: %w", err)
	}
	action := createAction(esClient, cfg)
	return action.Do()
}

View on GitHub (pinned to 806f444784)