Repository navigation
docs(snapshots): keep 14 days of snapshots, and async job cleanup timing - #2385
Conversation
✅ Pull with Spice PassedPassing checks:
|
🔍 Pull with Spice FailedPassing checks:
Failed checks:
Please address these issues and update your pull request. |
1 similar comment
🔍 Pull with Spice FailedPassing checks:
Failed checks:
Please address these issues and update your pull request. |
|
🚀 deployed to https://c9fc8a50.spiceai-org-website.pages.dev |
There was a problem hiding this comment.
🟡 Changes recommended
Lifecycle guidance can leave versioned storage growing indefinitely, and storage estimates omit retained files.
3 open findings
What changed in this PR
Updates vNext documentation for automatic snapshot retention and revised asynchronous query job cleanup.
Changes:
- Documents 14-day snapshot retention, protected snapshots, and delayed file deletion.
- Replaces lifecycle-based retention recommendations with publisher-managed cleanup.
- Documents hourly job cleanup, including failed and cancelled jobs.
| File | Description |
|---|---|
| website/docs/features/distributed-query/index.md | Updates job cleanup eligibility and timing. |
| website/docs/features/data-acceleration/snapshots.md | Explains retention, deletion grace, and upgrade behavior. |
| website/docs/deployment/read-write-separation.md | Revises snapshot retention and storage guidance. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…, versioned buckets
|
Copilot's review body lists only the 3 inline findings. All three are addressed in 42a5816 and their threads are resolved. There were no separate previously-missed items. |
|
🚀 deployed to https://cbba191d.spiceai-org-website.pages.dev |

spiceai/spiceai#15199 makes the instance that publishes a dataset's snapshots keep only the snapshots of the last 14 days, plus the current and newest snapshot at any age, and delete the dropped files 24 hours later. It also changes async query job cleanup: failed and cancelled jobs are now deleted 12 hours after they finish, and each scheduler runs cleanup about once an hour instead of every 10 minutes. Before this change, the docs said snapshot storage grows until a bucket lifecycle rule expires it, recommended such a rule (24–72 hours in the read/write separation guide), and said the scheduler deletes only expired jobs, every 10 minutes.
Pages changed
website/docs/features/data-acceleration/snapshots.md: new "Snapshot retention" section (14-day retention, current and newest kept, 24-hour file grace, hourly sweep of unnamed files, log line, rollback limited to listed snapshots, lifecycle-deleted files treated as failed downloads, current and newest entries kept when their file is gone); storage sentence (about 15 days of files) and the lifecycle best practice updated, including versioned and replicated buckets.website/docs/deployment/read-write-separation.md: retention guidance now points to Spice's own retention instead of a 24–72 hour lifecycle rule, with noncurrent-version and replication notes and a 15-day sizing estimate.website/docs/features/distributed-query/index.md: async job cleanup covers failed and cancelled jobs and runs about once an hour.Edits on the snapshots page avoid the sections changed by the open #2379 (pin and unpin, which already documents the
409 Conflictfor a snapshot whose file is gone) and the per-dataset snapshot settings sections.Versioned docs
vNext only. The merge commit
9fcf078eis in no release tag, includingv2.4.0-rc.1andv2.4.0-rc.2; the page notes that v2.4.0-rc.2 and earlier keep every snapshot, so rc testers see older entries dropped at the first publish after upgrading.Verification
spiceai/spiceai trunk at
9a25991b0384c7fc6b25fc838d6d71ce6f65ea57.pub(super) const SNAPSHOT_RETENTION: Duration = Duration::from_hours(14 * 24);(crates/runtime-acceleration/src/snapshot/retention.rs:35)pub(super) const FILE_GRACE: Duration = Duration::from_hours(24);(crates/runtime-acceleration/src/snapshot/retention.rs:41)"Snapshot cleanup of dataset '{}' dropped {aged_out} snapshots older than {} and deleted {deleted} snapshot files."(crates/runtime-acceleration/src/snapshot/mod.rs:2229), with 14 days rendered as14dbyformat!("{}d", secs / DAY)(crates/object_store_occ/src/cleanup.rs:64)SnapshotApiError::SnapshotNotFound { .. } => (mapped toStatusCode::NOT_FOUND(crates/runtime/src/http/v1/snapshots.rs:452)pub const DEFAULT_RESULT_TTL: Duration = Duration::from_hours(12);(crates/runtime/src/jobs/state.rs:25)matches!(self.status, JobStatus::Failed | JobStatus::Cancelled)(crates/runtime/src/jobs/state.rs:312)pub const PASS_INTERVAL: Duration = Duration::from_hours(1);(crates/object_store_occ/src/cleanup.rs:29) andDuration::from_millis(half.saturating_add(rand::random_range(0..=interval_ms)))(crates/object_store_occ/src/cleanup.rs:39)metadata.json, files deleted at a publish at least 24 hours after the drop, hourly sweep of unnamed files at least 24 hours old, retention runs only on publish, the first publish after upgrade drops older entries.if Some(entry.snapshot_id) == current || Some(entry.snapshot_id) == newest {(crates/runtime-acceleration/src/snapshot/retention.rs:111) precedesif gone.contains(&entry.snapshot) {(crates/runtime-acceleration/src/snapshot/retention.rs:114)match store.delete(path).await {(crates/object_store_occ/src/cleanup.rs:88); the noncurrent-version and replication guidance comes from the S3 documentation and was not run herebootstrap_on_failure_behavior, and the writer drops an entry whose file is gone once the entry is at least 24 hours old.npm run buildinwebsite/passed locally ([SUCCESS] Generated static files in "build"., exit 0; no broken links or anchors reported)