docs/wiki/4.20-Task-Archiving.md
Task archiving in Super Productivity moves completed tasks out of the active task list into separate archive storage. The goals are to keep the active list small and fast, reduce how much data is synced between devices, and ensure that every device ends up with the same archive by syncing what to archive (operations) rather than the full archive content. The archive is split into two tiers—recent and old—so recent data is synced more often while older data is kept but transferred rarely. Understanding why archiving exists, how the two tiers work, how archiving interacts with time tracking and sync, and that you can restore archived tasks helps you make sense of “finish the day,” reports, and sync behavior.
For how time is logged and where it is stored (including the archive), see [[4.14-How-Time-Is-Logged]]. For how task attributes change when a task is archived, see [[4.09-Task-Attributes]]. For restoring data from a backup file (different from restoring a single task from the archive), see [[2.02-Restore-Data-From-Backup]].
If every completed task stayed in the active list, that list would grow without bound. The app would have to load and sync thousands of tasks, which would:
So completed tasks are moved out of the active list into archive storage (on disk, not in the main in-memory list). They remain part of your data for reports and history, but they no longer appear in project lists, the Today view, or the Schedule. The app treats them as the same task (same ID); they are just in a different storage tier.
The archive is split into two tiers to balance access to recent data and sync size:
Why 21 days? — The threshold (e.g. 21 days since completion) is a balance: long enough that “recent” covers normal review and reporting needs, short enough that the recent tier doesn’t grow forever. Without periodically flushing recent → old, the recent archive would grow indefinitely and sync would get heavier. The flush keeps the recent tier bounded.
Conceptual roles:
Invariants: Subtasks are archived (and flushed) with their parent so the hierarchy is preserved. Task IDs are stored in a deterministic order so that when sync replays the same operations on every device, each device ends up with the same archive layout.
The app does not sync the full archive as one big file. Instead it syncs operations such as “archive these tasks” and “flush recent to old.” Each device:
Because the logic is deterministic, all devices end up with the same archive content without ever sending archive data over the network. That keeps sync payloads small and avoids transferring years of completed tasks. If an operation fails (e.g. flush), the app can roll back to the previous state so the archive stays consistent.
When a task is archived, its time-tracking data is moved with it into the recent archive. When the app flushes recent → old, all time-tracking in the recent tier is moved to the old tier (and the recent time-tracking store is cleared). So:
So archiving preserves time data for reporting; it just moves it into archive storage so the active list and frequent syncs stay light.
Think of two warehouses: a small active one (the list you see every day) and a larger archive with two shelves—a recent shelf (last ~21 days, synced often) and a deep shelf (older, updated only when the app flushes). When you complete tasks, the app moves them (and their time data) to the recent shelf. Periodically it moves old items from the recent shelf to the deep shelf. To sync, the app doesn’t ship the warehouses; it ships move instructions. Every device runs the same instructions and ends up with the same layout. If you need a task back in the active list, you restore it from the archive.