jaegertracing/jaeger · error

error reading %s from storage: %w

Error message

error reading %s from storage: %w

What it means

getOperationsV2 reads operation names (with span_kind) from the bucketed operation_names_v2 table; if the gocql iterator reports an error on Close(), the driver error is wrapped with the table name so operators know exactly which table-backed query failed.

Source

Thrown at internal/storage/v1/cassandra/spanstore/operation_names.go:205

		// Get operations for all spanKind
		casQuery = s.session.Query(s.table.queryStmt, query.ServiceName)
	} else {
		// Get operations for given spanKind
		casQuery = s.session.Query(s.table.queryByKindStmt, query.ServiceName, query.SpanKind)
	}
	iter := casQuery.Iter()

	var operationName string
	var spanKind string
	var operations []tracestore.Operation
	for iter.Scan(&spanKind, &operationName) {
		operations = append(operations, tracestore.Operation{
			Name:     operationName,
			SpanKind: spanKind,
		})
	}
	if err := iter.Close(); err != nil {
		err = fmt.Errorf("error reading %s from storage: %w", s.table.tableName, err)
		return nil, err
	}
	return operations, nil
}

View on GitHub (pinned to 806f444784)

Solutions

  1. Inspect the wrapped driver error and Cassandra logs for the root cause (timeout vs unavailable vs consistency failure).
  2. Retry the operation after cluster health is restored.
  3. Increase read timeout or adjust retry policy/consistency level in the Cassandra configuration if timeouts recur.
  4. Check bucket/table health with nodetool; run repair if replicas are inconsistent.
Defensive patterns

Strategy: retry

Try / catch

ops, err := reader.GetOperations(ctx, tracestore.OperationQuery{ServiceName: svc})
if err != nil {
    if strings.Contains(err.Error(), "error reading operation_names_v2") {
        // retry with backoff; check wrapped driver error
    }
    return err
}

Prevention

When it happens

Trigger: GetOperations call against the v2 schema where the Cassandra query on operation_names_v2 fails at scan/close time — read timeout, coordinator failure, consistency not achieved, or failing replica during the multi-bucket scan.

Common situations: Cassandra read timeouts on large services spanning many buckets; node outage; network partition between Jaeger and the cluster; overloading during heavy query traffic.

Related errors


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