bvandeusenandClaude Opus 5
e64d67e904
CI & Build / Python lint (push) Successful in 2s
CI & Build / TypeScript typecheck (push) Successful in 6s
CI & Build / Python tests (push) Successful in 12s
CI & Build / Build & push image (push) Successful in 44s
Desktop (Tauri) / Tauri desktop (Linux) (push) Failing after 1m45s
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 2m12s
Trash had no end. A note sat in /trash until someone emptied it by hand, and its attachment BYTES sat on disk the whole time — the pile-up the operator asked about. Nothing purged; there was no scheduler at all. Retention is server-owned: `trash_retention_days` (default 30, 0 = keep forever) in the settings registry, so it lands in admin Settings with no migration and takes effect without a restart. A background sweep started in before_serving does the work. Clients learn about a purge the way they learn about any deletion — as a tombstone on the delta feed. An auto-purge nobody can see coming is data loss on a timer, so the window is now visible: /api/config publishes it, notes carry `deleted_at`, Trash leads with the policy, and each card counts down. The countdown rounds DOWN — saying "1 day left" for a note with ten minutes on the clock is the one error here that actually costs someone a note. Three things this turned up on the way: - `DELETE /api/notes/<id>` hard-deleted the row, leaving no tombstone at all. A permanent delete in the web UI never reached a linked device, which would keep its copy forever and push it back on the next edit. It now purges through the same path as everything else. - The purge left `note_revisions` and `note_link_previews` behind. A revision holds the full body, so the text of a "permanently deleted" note was still sitting in the database. - `deleted_at` now SURVIVES a purge instead of being cleared. It's still true, and it means every query that says "not trashed" excludes tombstones for free — without it a content-less row reads as a perfectly normal active note and shows up on the board as a blank card. Desktop keeps its own clock only when there's nobody else to keep one: the sweep runs at startup on an UNLINKED device and refuses otherwise. A linked client that expired notes on its own schedule could destroy something the server was deliberately keeping, then push that delete upstream. Local policy must never outrank the server's — so it also adopts the server's window for the countdown rather than showing its offline default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi
78 lines
3.0 KiB
Rust
78 lines
3.0 KiB
Rust
//! The sync cycle (M10.7c).
|
|
//!
|
|
//! Deliberately the ONLY way the UI can sync. Push and pull are each usable on their
|
|
//! own inside this crate, but exposing them separately would let a caller pull
|
|
//! without pushing, which quietly overwrites unsent local edits.
|
|
|
|
use chrono::{SecondsFormat, Utc};
|
|
use serde::Serialize;
|
|
|
|
use super::blobs::BlobStore;
|
|
use super::pull;
|
|
use super::push;
|
|
use super::state;
|
|
use crate::local::Db;
|
|
|
|
#[derive(Debug, Serialize)]
|
|
pub struct SyncOutcome {
|
|
pub push: push::PushSummary,
|
|
pub pull: pull::PullSummary,
|
|
/// The state after the cycle, so the UI updates from one round-trip instead of
|
|
/// following every sync with a status call.
|
|
pub status: state::Status,
|
|
}
|
|
|
|
/// Push, then pull — in that order, always.
|
|
///
|
|
/// Pull writes the server's version straight over the local row, so anything not yet
|
|
/// sent would be lost to it. Pushing first is what puts the local edit in front of
|
|
/// the server's last-write-wins comparison, and it's the reason
|
|
/// `PullSummary::clobbered_dirty` should be zero on every healthy cycle.
|
|
///
|
|
/// A failed push aborts before the pull. Pulling anyway would take the exact rows we
|
|
/// just failed to save and overwrite them — turning a recoverable network error into
|
|
/// lost work.
|
|
pub async fn run_cycle(
|
|
db: &Db,
|
|
blobs: &BlobStore,
|
|
base_url: &str,
|
|
token: &str,
|
|
) -> Result<SyncOutcome, String> {
|
|
let push = push::run(db, base_url, token).await?;
|
|
let pull = pull::run(db, blobs, base_url, token).await?;
|
|
|
|
if pull.clobbered_dirty > 0 {
|
|
// Push ran first and reported success, so nothing should still have been
|
|
// dirty. Reaching here means something wrote to the store mid-cycle, or a
|
|
// change never got collected — worth a loud line either way.
|
|
log::warn!(
|
|
"sync cycle overwrote {} locally-edited note(s) despite pushing first",
|
|
pull.clobbered_dirty
|
|
);
|
|
}
|
|
|
|
// While we're already talking to this server, re-read what it says about itself.
|
|
// Today that's the trash-retention window the Trash view counts down against, and
|
|
// it can change under us whenever an admin edits the setting. Best-effort on
|
|
// purpose: a config blip must not fail a cycle whose actual work already
|
|
// succeeded, and the stored value simply stays as it was.
|
|
let retention = super::client::probe(base_url)
|
|
.await
|
|
.ok()
|
|
.and_then(|p| p.server.trash_retention_days);
|
|
|
|
let status = {
|
|
let conn = db.0.lock().map_err(|e| e.to_string())?;
|
|
if let Some(days) = retention {
|
|
state::set_server_retention(&conn, days as i64).map_err(|e| e.to_string())?;
|
|
}
|
|
// Stamped only here, after BOTH halves succeeded. A timestamp written after a
|
|
// partial cycle would tell the user they're up to date when they aren't.
|
|
let now = Utc::now().to_rfc3339_opts(SecondsFormat::Millis, true);
|
|
state::mark_synced(&conn, &now).map_err(|e| e.to_string())?;
|
|
state::status(&conn).map_err(|e| e.to_string())?
|
|
};
|
|
|
|
Ok(SyncOutcome { push, pull, status })
|
|
}
|