Scheduling uploads: past slots, a cron, and one stamp

The scheduler in Autoretto used to be a simple countdown. Pick a future timestamp, set a timer, and hope the machine was awake when it fired. That works for a single upload on a laptop. It falls apart when you run seven channels from one server with no one watching the screen.

So we changed the mental model. The scheduler no longer asks "when should the next video go up?" It asks "which slot was the most recent one we missed?" That slot is the anchor. If you have a twice weekly schedule, the slots are Monday and Thursday at noon. The system looks back from the current moment to find the latest slot that has not yet been filled. That becomes the thing to publish.

Why look backward instead of forward? Because a future timestamp is a promise. If the process restarts, that promise evaporates. A past slot is a fact. It exists in the calendar no matter what. The scheduler can always find it and then decide if the slot has content. The decision is deterministic. Two different scheduler runs, even a minute apart, will agree on which slot is due.

The catch-up window matters here. We only look back so far, usually about two days. If a slot is older than that, we treat it as skipped, not due. This prevents a channel from dumping ten videos after a week long outage. The system wants to fill the recent gap, not the entire history. That keeps the channel's rhythm recognizably close to the plan.

Now, the actual upload does not happen inside a long running scheduler process. The scheduler is a cron that fires every hour. It wakes up, checks the state file, and asks a simple set of questions. Has the latest due slot already been published? If yes, do nothing. If no, pick the video that was prepared for that slot and start the publishing flow. No browser needs to be open. No human has to click anything.

The cron runs server side, but we also run a local version on a creator's machine. That version uses the same logic and the same state file. The trick is to avoid a double publish when both the server cron and the desktop version are active. That is where the last release stamp comes in. The state file stores a timestamp and a slot identifier for the most recent successful upload. Any scheduler that wants to publish must read that stamp first.

When a scheduler checks a due slot, it compares the slot time against the stamp. If the stamp is newer or equal to the slot time, the slot is done. If the stamp is older, the scheduler attempts to claim the slot by writing a temporary lock. Only the process that wins the lock can upload. After the upload finishes, it updates the stamp to the current time. The losing process sees the new stamp on its next check and backs off.

This design did not come from a whiteboard. It came from real failures. We watched our bots trip over each other and miss slots for reasons no one could explain at three in the morning. The past slot anchor fixed the timeline. The cron fixed the reliability. The stamp fixed the race condition. Together they make scheduling boring, which is exactly what we want.