jaegertracing/jaeger · error
error reading service_names from storage: %w
Error message
error reading service_names from storage: %w
What it means
GetServices lists distinct service names from the service_names table; if the gocql iterator returns an error when closed (the query failed during or after scanning), the driver error is wrapped with this message so the caller knows the service-name listing read failed in storage.
Source
Thrown at internal/storage/v1/cassandra/spanstore/service_names.go:97
// it simply means we might write the same service name twice.
inCache := c.Get(key)
if inCache == nil {
c.Put(key, key)
}
return inCache != nil
}
// GetServices returns all services traced by Jaeger
func (s *ServiceNamesStorage) GetServices() ([]string, error) {
iter := s.session.Query(s.QueryStmt).Iter()
var service string
var services []string
for iter.Scan(&service) {
services = append(services, service)
}
if err := iter.Close(); err != nil {
err = fmt.Errorf("error reading service_names from storage: %w", err)
return nil, err
}
return services, nil
}
View on GitHub (pinned to 806f444784)
Solutions
- Retry GetServices after checking cluster health; it is a cheap read-only call.
- Inspect the wrapped driver error and Cassandra logs for the root cause.
- Tune Cassandra read timeouts/retry policy if timeouts are common.
- Verify the service_names table exists and is readable (permissions, schema version).
Defensive patterns
Strategy: retry
Try / catch
services, err := reader.GetServices(ctx)
if err != nil {
if strings.Contains(err.Error(), "error reading service_names") {
// transient read failure: retry with backoff
}
return err
} Prevention
- Monitor the frequently-hit service_names table for timeouts.
- Set sane client timeouts and retries for Cassandra reads.
- Verify the table exists post-migration in readiness checks.
- Cache the service list briefly in clients to reduce read pressure.
When it happens
Trigger: Calling GetServices on the service/operation names storage while the underlying SELECT from service_names fails — Cassandra read timeout, node unavailability, or connection error during the scan.
Common situations: Cluster under load (timeouts on the small but frequently-hit service_names table); network issues; node restarts; stale schema state after failed migrations.
Related errors
- error reading operation_names from storage: %w
- error reading %s from storage: %w
- invalid version
- failed to Exec query '%s': %w
- failed to acquire resource lock due to cassandra error: %w
AI-assisted analysis of jaegertracing/jaeger@806f444784 (2026-09-01).
Data as JSON: /api/errors/7181d963fe9f587b.
Report an issue: GitHub.