Decide: retention policy for old calculation runs #16
Labels
No labels
bug
decision
docs
enhancement
integration
ops
security
tech-debt
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
rbrooks/BatteryStorageCalculator#16
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Open Question carried over from
docs/roadmap.md.Milestone 15 checked off
Add cleanup policy for old calculation runs, so a policy exists in code - this issue is about confirming the retention window is the one actually wanted, and reconciling it with the authoritative-vs-derived decision.Relevant context: the output column is large (a 344KB output blob was the cause of a fixed polling performance bug), so retention has a real storage and query cost.
Partially answered by the #15 decision (2026-07-17): results are cacheable derivations, so retention needs no long history — always keep the latest completed result (the #32 fix), cap failed rows separately, and prune the rest freely. The only question left open here is the actual window size (current: 25 rows); anything needing to survive longer belongs in a report snapshot. Left open for that final sizing call.