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.

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