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

  1. Check the wrapped driver error in logs for the real cause (connection, missing relation, timeout)
  2. Verify the ttl_setting table and its org_id/status/created_at columns exist
  3. Apply pending migrations and confirm indexes on (org_id, status, created_at)
  4. 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

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


AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28). Data as JSON: /api/errors/5ac8010c1f3cef95. Report an issue: GitHub.