Question: How to detect live publish/unpublish/delete during a long initial sync?

[pithu]

Package: @contentstack/datasync-manager v2.2.0
Context: Server-side mirror sync (DocumentDB/S3) driven by datasync-manager, with many concurrent content editors and initial syncs that can run for a long time.

The documentation note

I remember Contentstack documenting that if content changes while an initial sync is still paginating, you must restart from init. I could not find this on the CDA Synchronization API reference, but it appears on the Use Sync API With JavaScript SDK page (Sync pagination + FAQ):

Note: If any changes are made to the entries (if any actions i.e., Unpublish/Publish/Delete have been performed), then you need to run the init call again and generate a new pagination_token to fetch the remaining records.

Same wording under “When should I run the init call again?”

Our situation

We run full initial syncs via datasync-manager against a busy stack. With many editors publishing throughout the day, it is hard to pick a maintenance window where the stack is effectively frozen.

If live edits during pagination invalidate the in-progress sync, we need a reliable way to detect that condition and decide whether to restart init or run a follow-up catch-up.

Questions

1. Does datasync-manager detect or handle this case today?
   If publish/unpublish/delete events occur while an init + pagination_token run is in progress, does the manager restart, warn, or silently continue?

2. What is the recommended detection strategy?
   For example:

   • Compare total_count from a subsequent sync_token / start_from query against zero?
   • Track event_at timestamps on returned items?
   • Always restart init if any delta exists after sync completes?
   • Something else?

3. Is there a supported pattern for “sync until quiescent”?
   e.g. run initial sync → check for edits since sync start → if any, re-run init (or incremental catch-up) until no edits are reported.

4. Should this guidance live in datasync-manager docs?
   The note seems easy to miss on the SDK page and absent from the API reference. A short section on operational handling of concurrent edits during long initial syncs would help.

What we are experimenting with

After a test sync we call the Sync API with startFrom set to the job start time and treat a non-zero total_count as “edits happened during the run”. We are unsure whether that matches Contentstack’s intended workflow or if datasync-manager has a better built-in approach.

Any guidance or recommended pattern would be appreciated.