SigNoz/signoz · error · errors.base
internal
internal
Error message
load ttl_setting rows for org %q table %q
What it means
The retention store's ListTTLSettingsByTableNameAndBeforeCreatedAt query (org_id + status=success + created_at < beforeMs, ordered ASC) failed at the database and is wrapped as an internal error naming the org and table. Used by GetRetentionPolicySegments to load completed TTL settings for compaction/retention processing.
Source
Thrown at pkg/modules/retention/implretention/store.go:37
return &store{sqlstore: sqlstore}
}
// ListTTLSettingsByTableNameAndBeforeCreatedAt returns successful TTL settings before the given timestamp.
func (store *store) ListTTLSettingsByTableNameAndBeforeCreatedAt(ctx context.Context, orgID valuer.UUID, tableName string, beforeMs int64) ([]*retentiontypes.TTLSetting, error) {
rows := []*retentiontypes.TTLSetting{}
err := store.
sqlstore.
BunDB().
NewSelect().
Model(&rows).
Where("table_name = ?", tableName).
Where("org_id = ?", orgID.StringValue()).
Where("status = ?", retentiontypes.TTLSettingStatusSuccess).
Where("created_at < ?", time.UnixMilli(beforeMs).UTC()).
OrderExpr("created_at ASC").
Scan(ctx)
if err != nil {
return nil, errors.Wrapf(err, errors.TypeInternal, errors.CodeInternal, "load ttl_setting rows for org %q table %q", orgID.StringValue(), tableName)
}
return rows, nil
}
View on GitHub (pinned to 5069bf80b0)
Solutions
- Check the wrapped driver error in logs for the real cause (connection, missing relation, timeout)
- Verify the ttl_setting table and its org_id/status/created_at columns exist
- Apply pending migrations and confirm indexes on (org_id, status, created_at)
- Retry after DB health is restored; investigate slow queries if it is a timeout
Defensive patterns
Strategy: retry
Try / catch
try { segments = await getRetentionPolicySegments(orgID, tableName, beforeMs); } catch (e) { if (e.type === 'internal' && /load ttl_setting rows/i.test(e.message)) { await sleep(backoff()); segments = await getRetentionPolicySegments(orgID, tableName, beforeMs); } else throw e; } Prevention
- Ensure migrations for ttl_setting run before enabling retention jobs
- Index ttl_setting(org_id, status, created_at) to avoid timeouts
- Alert on retention job failures and page on repeated internal errors
When it happens
Trigger: Running retention policy segment computation when the ttl_setting table is missing/corrupted, the DB is unreachable, or the created_at/org_id/status columns have schema drift; also possible query timeouts on large tables.
Common situations: Failed or skipped migration creating ttl_setting, Postgres outage, version upgrade changing the ttl_setting schema, heavy table without expected indexes causing timeouts.
Related errors
- CodeInternal
- couldn't create cloud integration service account: %w
- SetTTLV2 only supported
- error in processing TTL
- error in processing ttl_status check sql query
AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28).
Data as JSON: /api/errors/5ac8010c1f3cef95.
Report an issue: GitHub.