Skip to content

Sync: bound iOS cr-sqlite replica catch-up with a too-far-behind reseed (post-#869) #873

Description

@arul28

Why

PR #869 (merged, 73e8d633a) closed the changeset-starvation symptom for web / roster / terminal (browser invalidation-only reseed, per-peer poll fairness, capped PTY transcripts). The one residual path: the iOS cr-sqlite replica pump (apps/ade-cli/src/services/sync/syncHostService.ts ~:5026) still exports the backlog forward in bounded batches (250 rows / 256KB) from the peer's watermark — bounded per batch, unbounded in total. A phone offline a long time grinds the whole backlog instead of jumping to current. Roster and browser peers already get a full-snapshot reseed; replica peers with a baseline do not.

Approach (~1 file)

  • In pumpChanges for replica peers (isMobileChangesetPeer), add a too-far-behind guard: when currentDbVersion - peer.lastKnownServerDbVersion exceeds ~1000-5000, skip incremental replay and send a one-shot compacted reseed (CRR-compacted single changeset or out-of-band .ade/ade.db snapshot), then reset the peer watermark to currentDbVersion. Mirror the existing sendRosterSnapshotToPeer reseed pattern for the changeset path.

Severity

Throughput/latency on huge gaps, not correctness — indefinite starvation is already fixed by #867 (2s cap) + #869. Low urgency.

Acceptance

  • A replica > threshold behind receives a single reseed and jumps to current instead of replaying the entire backlog.

Related

ADE-123 (sync-host reliability), PR #869. Source: this session's sync analysis.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions