thanos-io/thanos · error
could not calculate retention progress
Error message
could not calculate retention progress
What it means
rs.ProgressCalculate(ctx, retGroups) runs the RetentionProgressCalculator, which estimates how many blocks would be deleted by the configured retention policy per resolution. Failures are wrapped as 'could not calculate retention progress'. It is a metrics-only step in the periodic progress worker.
Solutions
- If the inner error is 'context canceled', ignore it — it happens during graceful shutdown; check shutdown ordering in run.Group.
- Inspect the wrapped error for the failing group and validate block metadata with 'thanos tools bucket inspect'.
- Confirm retention flag values (--retention-resolution-raw etc.) parse as valid durations; fix invalid retention configuration.
- Upgrade Thanos if the calculator errors on valid groups.
Example fix
// before --retention-resolution-raw=14d --retention-resolution-5m=bd # invalid duration // after --retention-resolution-raw=14d --retention-resolution-5m=1s # or omit 5m retention
Defensive patterns
Strategy: try-catch
Validate before calling
// Validate retention flags parse as durations before wiring the calculator
for _, d := range []string{rawRetention, res5mRetention, res1hRetention} {
if _, err := time.ParseDuration(d); err != nil {
log.Fatalf("invalid retention duration %q", d)
}
} Try / catch
if err := rs.ProgressCalculate(ctx, retGroups); err != nil {
if ctx.Err() != nil {
return nil // graceful shutdown
}
log.Errorf("could not calculate retention progress: %v", err)
return nil
} Prevention
- Pass retention flags as valid Go durations (e.g. 14d handled by Thanos, otherwise 336h).
- Ignore 'context canceled' during shutdown — it's expected.
- Fix grouping issues upstream before retention calculation.
- Keep retention config in one reviewed place (YAML where available).
When it happens
Trigger: The retention calculator errors while applying retentionByResolution to the groups — typically when ctx is cancelled (shutdown) or when group/block state is inconsistent from earlier metadata problems.
Common situations: Most often seen as 'context canceled' during compactor shutdown while the progress loop is mid-calculation; also after bad grouping state caused by duplicate blocks.
Understand the failure class
Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.
Related errors
- raw resolution must be higher than the minimum block size…
- 5m resolution retention must be higher than the minimum…
- sync before retention
- retention failed
- could not calculate compaction progress
AI-assisted analysis of thanos-io/thanos@35b8b99117 (2026-09-07).
Data as JSON: /api/errors/52d562f3ac08a268.
Report an issue: GitHub.
Appendix: source
Thrown at cmd/thanos/compact.go:679
}
metas := sy.Metas()
groups, err := grouper.Groups(metas)
if err != nil {
return errors.Wrapf(err, "could not group metadata for compaction")
}
if err = ps.ProgressCalculate(ctx, groups); err != nil {
return errors.Wrapf(err, "could not calculate compaction progress")
}
retGroups, err := grouper.Groups(metas)
if err != nil {
return errors.Wrapf(err, "could not group metadata for retention")
}
if err = rs.ProgressCalculate(ctx, retGroups); err != nil {
return errors.Wrapf(err, "could not calculate retention progress")
}
if !conf.disableDownsampling {
groups, err = grouper.Groups(metas)
if err != nil {
return errors.Wrapf(err, "could not group metadata into downsample groups")
}
if err := ds.ProgressCalculate(ctx, groups); err != nil {
return errors.Wrapf(err, "could not calculate downsampling progress")
}
}
return nil
})
}, func(err error) {
cancel()
})
}View on GitHub (pinned to 35b8b99117)