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
- Inspect the wrapped driver error and Cassandra logs for the root cause (timeout vs unavailable vs consistency failure).
- Retry the operation after cluster health is restored.
- Increase read timeout or adjust retry policy/consistency level in the Cassandra configuration if timeouts recur.
- 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
- Keep Cassandra cluster healthy; alert on read timeouts/unavailables.
- Tune read timeout and retry policy in Jaeger's Cassandra options.
- Run regular nodetool repairs on operation_names_v2.
- Avoid pathological service cardinality that explodes bucket scans.
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
- error reading operation_names from storage: %w
- error reading traces from storage: %w
- error reading service_names from storage: %w
- invalid version
- failed to Exec query '%s': %w
AI-assisted analysis of jaegertracing/jaeger@806f444784 (2026-09-01).
Data as JSON: /api/errors/671e5f872880e2f5.
Report an issue: GitHub.