The 9am post goes out at 9am. Here is the mechanism.

Most schedulers hold your schedule in the memory of a running program. If that program restarts — a deploy, a crash, a server that ran out of memory at 3am — the schedule it was holding is gone. Nothing errors, nothing alerts, and you find out when the client asks.

Gongong AI keeps the schedule in the database and asks it every thirty seconds what is due. When a post is claimed for publishing, the instruction to publish it is written in the same transaction as the claim, so there is no instant where we have ticked a post off as handled but not yet told anything to send it. The message queue can be down at that moment and the post is still safely queued, waiting for the relay. Several machines can work the same due list without colliding, because each one takes the rows the others are not holding and steps over the rest — which is what stops a post being picked up twice and posted twice to a real audience.

Then there is a second pass on a longer clock. The queue’s lock on a post lasts eight minutes; the recovery pass sweeps for anything still stuck after ten. Ten is longer than eight on purpose — the recovery pass must never grab a post a still-alive machine is in the middle of publishing.

When a network refuses, the failure is classified rather than retried blindly. An expired token pauses the account and asks you to reconnect, because replaying a dead token three times burns the platform’s rate budget. A rate limit reschedules to the platform’s own reset time rather than backing off into the same closed window. A transient error retries three times with jittered backoff — the one class where retrying is the right answer. A rejection stops, shows a human-readable reason on the post card and fires a webhook. And when the platform says it already has the post, that counts as success and the IDs are reconciled, because retrying would post a second copy to real followers.

Two separate anti-duplicate keys make that last one work. One is stable per post and account and is handed to the platform, so the platform de-duplicates if our request times out ambiguously. The other changes on every attempt and is ours, so our own queue can tell attempt two from attempt one. Putting the attempt number in the platform-facing key would cause exactly the double-post it exists to prevent.