Skip to content

refactor(sync)!: delete the old sync engine and publish sync-v2 - #325

Merged
mohamede1945 merged 7 commits into
feat/sync-v2-importerfrom
refactor/remove-old-sync-engine
Oct 14, 2026
Merged

mohamede1945 merged 7 commits into
feat/sync-v2-importerfrom
refactor/remove-old-sync-engine

Conversation

@mohamede1945

@mohamede1945 mohamede1945 commented Oct 14, 2026 •

Copy link
Copy Markdown
Collaborator

Stacked on #324 (importer), then #323 (wiring) and #322 (engine). This is port step 4 of 5.

Summary

Deletes the old sync engine now that sync-v2 runs behind QuranDataService. The diff is about −15,100 / +210 lines.

  • Moved the shared types still in use into sync-pipelines. SyncError, SyncErrorKind and SynchronizationEnvironment are now in com.quran.shared.pipeline; SyncLifecycleGate is in com.quran.shared.pipeline.sync. Their ObjC/Swift names are unchanged. SyncRunObserver, SynchronizationClient, SyncOperationInvalidatedException, SchedulerTimings and FailureRetryingConfig are now internal.

  • Deleted the syncengine module:

    • adapters and preprocessors;
    • conflict detectors and resolvers;
    • ACK validation and replay;
    • the old scheduler;
    • the GET/POST request classes;
    • the Sync* models and their tests.

    mutations-definitions loses only the unused MutationType.kt; it keeps ServerText* and AppScope.

  • The sync HTTP client is built the way auth builds its own: OkHttp on jvm/android, Darwin on iOS, the logging plugin, and Accept: application/json.

  • Docs: SYNCENGINE_ARCHITECTURE.md is replaced by a short SYNC_ENGINE.md. README and AGENTS.md are updated.

  • Publishing: com.quran:sync-v2 is now published. persistence and mobile-sync depend on it since feat(sync)!: run sync on the sync-v2 engine and plain tables #323, so without this a release would publish POMs that can't be resolved. Verified with the release workflow's publishToGitHubPages into a scratch repo: every com.quran dependency resolves. No workflow change is needed.

Compatibility

  • Shared.h: nothing added. 79 old-engine or now-internal types were removed. Some Kotlin/Native selector disambiguations on third-party types changed (Job, Ktor Attributes).
  • iOS and Android: neither app uses any removed or renamed type; quran-ios, quran-ios-private and quran_android were all grepped. Android Kotlin that imports SynchronizationEnvironment/SyncError imports them from com.quran.shared.pipeline.

Tests

  • ./gradlew allTests --continue passes, and so do :umbrella:linkDebugFrameworkIosSimulatorArm64, :demo:android:assembleDebug and umbrella:assembleSharedXCFramework.
  • The integration suite has 299 tests. Only S4 (NOTE-12, which needs the iOS Note ranges model) remains as a knownIssue.
  • Reviewed by a separate reviewer. Its three nits are fixed in the last commit: the Accept header, the POM descriptions and SYNC_ENGINE.md.

🤖 Generated with Claude Code

Cleanup (rebased 2026-10-14)

  • Added SyncErrorMappingTest for toSyncError(). The deleted SyncErrorTest used to cover it.
  • AGENTS.md now points to SYNC_ENGINE.md instead of repeating it.

@mohamede1945
mohamede1945 added this pull request to stack #326 October 14, 2026 14:05
mohamede1945 and others added 7 commits October 14, 2026 11:29
The sync-v2 client in sync-pipelines still used a few types from the old
syncengine module. They now live next to the code that uses them, and
sync-pipelines, umbrella and the Android demo no longer depend on
syncengine:

- SyncError, SyncErrorKind and SynchronizationEnvironment move to
  com.quran.shared.pipeline (next to SyncStatus and AppEnvironment).
  They stay public; their ObjC/Swift names are unchanged.
- SyncLifecycleGate moves to com.quran.shared.pipeline.sync and stays
  public, since SessionLifecycleCoordinator implements it.
- SyncRunObserver, SynchronizationClient,
  SyncOperationInvalidatedException, SchedulerTimings and
  FailureRetryingConfig move to com.quran.shared.pipeline.sync and
  become internal: only the old engine's builder took them publicly.
- HttpClientFactory goes: SyncClient builds its Ktor client like auth
  does, with the platform engine (OkHttp, Darwin) from sync-pipelines'
  own dependencies.

Shared.h drops SynchronizationClient, SyncOperationInvalidatedException,
SchedulerTimings, FailureRetryingConfig, HttpClientFactory and the old
engine's exported types; neither app uses them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
QuranDataService runs sync-v2, and nothing uses the syncengine module
any more. Delete it with its tests: the per-resource adapters, local
and remote preprocessors, conflict detectors and resolvers, pushed
mutation ACK validation, the replay of creates, the scheduler
(replaced by SyncScheduler), the GET/POST request classes (replaced by
sync-v2's SyncApi), and the Sync* models.

mutations-definitions stays for the ServerText helpers and AppScope;
its mutation types (Mutation, LocalModelMutation, RemoteModelMutation,
LocalMutationAck, LocalMutationResource) only served the old engine and
go too.

The com.quran:syncengine artifact is no longer published.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…E.md

SYNCENGINE_ARCHITECTURE.md described the deleted syncengine module.
SYNC_ENGINE.md is a short map of sync-v2 (working, base and sync state;
fetch, merge, push; where sync-pipelines runs it) that points to the
KDoc for details.

README and AGENTS.md drop the syncengine module and its commands, say
where the public sync types live now, and describe what
mutations-definitions still holds. The README's custom-endpoint example
imports SynchronizationEnvironment from com.quran.shared.pipeline.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The published persistence and mobile-sync artifacts depend on sync-v2,
but sync-v2 had no publishing set up, so their POMs and Gradle module
metadata pointed at com.quran:sync-v2, which no repository served.
Android builds could not resolve mobile-sync.

Apply the vanniktech maven-publish plugin with the same mavenPublishing
block as the other modules. The release workflow's
publishToGitHubPages step publishes every module that applies the
plugin, so it now ships sync-v2, sync-v2-android and sync-v2-jvm with
no workflow change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- The sync HTTP client sends `Accept: application/json` on every request
  again. The old client got it from ContentNegotiation.
- The mutations-definitions and umbrella POM descriptions no longer
  mention mutation tracking or the old SyncEngine.
- SYNC_ENGINE.md lists everything `sync_meta` holds: the token, the
  account, the outbox, the wipe epoch and the hold bookkeeping.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deleting the old engine took SyncErrorTest with it, which covered the
mapping the app sees in syncStatus. SyncResult.Failed.toSyncError() had
no unit test: the integration scenarios reach only its 403 and 503
branches. Pin the status-to-kind table, that the status and the
server's code are kept, that no response body or server message leaks
into the message, network errors (also wrapped ones), and the unknown
fallbacks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SYNC_ENGINE.md now maps the engine, so AGENTS.md's sync-v2 section
keeps only the operational steps (adding a synced type, keeping the two
fakes in step) and points to it for the model. SYNC_ENGINE.md gains
what only AGENTS.md said: the three states compared per item and when a
hold ends. The README's sync overview links to it, and SYNC_ENGINE.md
links to the integration test guide.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mohamede1945
mohamede1945 force-pushed the refactor/remove-old-sync-engine branch from ad257ab to b4b3d92 Compare October 14, 2026 15:36
@mohamede1945
mohamede1945 merged commit b1a17f8 into main Oct 14, 2026
1 check passed
@mohamede1945
mohamede1945 deleted the refactor/remove-old-sync-engine branch October 14, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant