Sync rules and limits

Decision table#

A sync reads the remote manifest and decides for each file as below. The on-screen preview and the actual sync use the same decision function, so what you see in the preview is exactly what happens.

• Every write applies only to "files that came from a remote file_id". Directly uploaded files are not subject to decisions.
• The checksum is computed over the bytes the storage actually wrote and compared with the manifest. A file truncated in transit does not pass as a good file. On a mismatch, only that file is discarded and a warning recorded.
• The remote's per-file meta and the original file name are kept in the platform file's meta.source.
• If only the name changes under the same file_id and the content (sha256) is the same, it is "kept". The platform's file name does not change.

Transfer order#

Annotation files are fetched last. Annotation validation pairs annotations with images already in the dataset, and fetching in manifest order (0001.json < 0001.png) would give 0% pairing. At the end of the run, annotations are validated once more so that images that arrived in a later run are matched too.

Run control#

Starting a sync through the API returns 202 and the run row immediately. Check progress by reading GET /api/v1/datasets/{id}/syncs/{sync_id} or the run list again; cancel with POST /api/v1/datasets/{id}/syncs/{sync_id}:cancel. status goes PENDING → RUNNING → SUCCEEDED · FAILED · CANCELED.

curl -b cookies.txt -H "X-Tenant: DEMO" -X POST \
  "http://localhost:10000/api/v1/datasets/<dataset id>/syncs"
# calling again while it runs:
# {"error_id":"…","code":"conflict","message":"a sync is already running for this dataset","detail":null}

Server settings#

Unsupported features#