Running a sync
How a reviewed run is queued, executed, verified and retried.
Queued and durable
A run is queued in PostgreSQL and executed by the sync worker, a separate process. When you queue it, the run binds the selected non-secret configuration; when it starts, it checks that configuration and the AWS identity again. A changed setup refuses rather than running something you did not review.
One sync is queued or running at a time, across all users. While one is, a
new run is refused with 409 sync_run_active. A queued run that is already
marked for cancel does not count.
Runs support cancellation, deadlines and partial-failure accounting. Failed resources are recorded so you can retry only those.
Concurrency
Mappings run with bounded, CPU-aware concurrency. The default caps per service are ECR 4, S3 3, CodeCommit 3 and DynamoDB 3, and can be overridden with environment variables.
Verification, per service
| Service | What is verified |
|---|---|
| ECR | Root digest and descriptor-set equality after every tag write |
| S3 server-side copy | A destination HEAD bound to the copy receipt |
| S3 local upload | What actually landed |
| CodeCommit | Final source and destination ref parity |
| DynamoDB | Strong per-item reads |
The S3 worker relay does not read back uploaded bytes; it keeps a per-object
upload journal. S3 Batch records a waybill whose content verification is
marked not_checked.
S3 worker relay limits
The relay stages all selected bytes before upload. A run is refused when the selected bytes plus a 1 GiB reserve exceed the free space, and each mapping has a one-hour cooperative deadline. For larger moves, use server-side copy or S3 Batch Operations.
Notifications
The console shows an inbox, a bell and a status pill, driven by a status-only WebSocket. There are no external notifications: no email, webhook, Slack or SNS.
Nothing runs on its own
There is no scheduling of any kind on the server. A run happens only when a person starts it or a queued job is picked up.