Build a scheduled sync that copies records from one source into a destination without losing its place after a failure. Use it for a recurring import with a clear record identity and update policy.
Open your project, or start in an empty workspace with synthetic source data. Identify the source API, destination store, and schedule before connecting live systems. The handoff supplies no project context, access tokens, or configured schedule.
You get a bounded sync worker, persisted progress, and recovery checks. Scheduling and retries can repeat or miss invocations, so the implementation reconciles records instead of promising exactly-once execution.
Build a scheduled data sync that copies a bounded batch of source records into a destination and resumes safely after interruption. Keep the first version to one source, one destination, and an explicit record identity and update policy. Read repository instructions and inspect the framework, package manager, storage adapters, scheduling setup, and tests. Preserve existing choices and compatible SDK versions. If an intended existing project is missing, ask me to open or import it. For an empty workspace, choose a small TypeScript application and begin with synthetic source and destination adapters. Ask for the real source, destination, schedule, and conflict policy before connecting them; do not invent production endpoints or credentials. Implement the worker separately from its scheduler. Preserve an existing scheduler. For a new app, prefer a private Edgenivo Schedules function target if the team has beta access and the framework supports it; verify current setup requirements and keep its trigger private. Otherwise explain the available options before provisioning. Do not silently migrate Cron Jobs. For any public HTTP path target, verify CRON_SECRET before work and fail closed when it is missing; handleSchedule does not replace this check. Headers describing a schedule are not authentication. Keep credentials server-side and prevent cached or redirected trigger responses. Use durable progress and stable source record IDs. Make writes idempotent with unique keys or upserts, and define how source updates overwrite destination data. Persist a cursor only after the corresponding writes succeed. If writes and checkpoints cannot share a transaction, make replay safe and test the crash window. Validate pagination semantics with the source provider; avoid advancing past failed records or skipping updates that arrive during a run. Bound each invocation by records, requests, and elapsed time. Use an atomic lease with ownership checks to prevent overlapping workers from corrupting progress, including after lease expiry. Record counts, checkpoint, and a redacted failure reason. Retry only transient failures with a bounded policy that respects source throttling. Leave exhausted work recoverable for a later authorized run. Never assume the scheduler retries failures, guarantees every run, or delivers exactly once. Keep remote deletions outside this version. Use disposable fixtures to test initial import, repeated runs, source updates, invalid credentials, unauthorized triggers, concurrent runs, throttling, and a crash between writing data and saving progress. Confirm recovery produces complete destination records without duplicates. Run relevant type, lint, and worker tests without writing to live systems. Report local invocation steps, configuration names, actual results, unrun integration checks, and remaining consistency limits. Ask before provisioning services, enabling a schedule, deploying, or syncing live data.