snegov/cura-te-ipsum
1
0 Fork 0
Code Issues 20 Releases Wiki Activity

Weekly retention bug: same ISO week number across years treated as duplicates #33

New Issue
Closed
opened 2026-02-05 05:23:40 +00:00 by snegov · 1 comment
snegov commented 2026-02-05 05:23:40 +00:00
Owner
Copy link
Copy source

Bug Description

The weekly retention policy incorrectly treats backups from the same ISO week number in different years as duplicates. For example, backups from week 52 of 2021 and week 52 of 2022 are treated as the same week, causing one to be removed.

Root Cause

cleanup_old_backups() compares only the ISO week number when determining weekly duplicates:

# curateipsum/backup.py:274-275
if (_date_from_backup(prev_backup).isocalendar()[1]
        == _date_from_backup(backup).isocalendar()[1]):

This compares only isocalendar()[1] (week number 0-53) without checking isocalendar()[0] (ISO year).

Impact

  • Backups from the same week number in consecutive years are incorrectly deduplicated
  • Affects any week number (1-52), not just year boundaries
  • User may lose backups they expect to be retained by keep_weekly policy

Evidence

Test test_iso_week_number_across_years demonstrates the bug:

  • Creates backups on 2021-12-27 (ISO week 52 of 2021) and 2022-12-26 (ISO week 52 of 2022)
  • With keep_weekly=10, both should be kept (different ISO weeks)
  • Actual: only one kept (same week number 52)

Proposed Fix

Compare both ISO year and week number:

if (_date_from_backup(prev_backup).isocalendar()[0:2]
        == _date_from_backup(backup).isocalendar()[0:2]):

This compares the tuple (ISO_year, ISO_week) instead of just the week number.

Related

  • Test marked as @pytest.mark.xfail until fixed
  • Similar pattern may affect other retention tiers (needs verification)
## Bug Description The weekly retention policy incorrectly treats backups from the same ISO week number in different years as duplicates. For example, backups from week 52 of 2021 and week 52 of 2022 are treated as the same week, causing one to be removed. ## Root Cause `cleanup_old_backups()` compares only the ISO week number when determining weekly duplicates: ```python # curateipsum/backup.py:274-275 if (_date_from_backup(prev_backup).isocalendar()[1] == _date_from_backup(backup).isocalendar()[1]): ``` This compares only `isocalendar()[1]` (week number 0-53) without checking `isocalendar()[0]` (ISO year). ## Impact - Backups from the same week number in consecutive years are incorrectly deduplicated - Affects any week number (1-52), not just year boundaries - User may lose backups they expect to be retained by `keep_weekly` policy ## Evidence Test `test_iso_week_number_across_years` demonstrates the bug: - Creates backups on 2021-12-27 (ISO week 52 of 2021) and 2022-12-26 (ISO week 52 of 2022) - With `keep_weekly=10`, both should be kept (different ISO weeks) - Actual: only one kept (same week number 52) ## Proposed Fix Compare both ISO year and week number: ```python if (_date_from_backup(prev_backup).isocalendar()[0:2] == _date_from_backup(backup).isocalendar()[0:2]): ``` This compares the tuple `(ISO_year, ISO_week)` instead of just the week number. ## Related - Test marked as `@pytest.mark.xfail` until fixed - Similar pattern may affect other retention tiers (needs verification)
snegov commented 2026-10-11 18:29:55 +00:00
Author
Owner
Copy link
Copy source

Fixed in fd613ed (#8): weekly grouping keys on isocalendar()[:2] (ISO year, week), so the same week number in different years is no longer a duplicate. The xfail on the test is gone; tests/test_backups.py passes (54).

Fixed in fd613ed (#8): weekly grouping keys on isocalendar()[:2] (ISO year, week), so the same week number in different years is no longer a duplicate. The xfail on the test is gone; tests/test_backups.py passes (54).
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
snegov (Maks Snegov)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: snegov/cura-te-ipsum#33