A queue in front of a simulcast, and the double-post it invites

The fan-out half later became zensocial. What is specific here is the queue, and putting one in front of a cross-poster changes the problem more than it should.

Posting immediately is stateless: every failure is visible right then and the user is there to react. A queued post is a promise to act later, so the state has to survive a restart, and the world changes between accepting the post and sending it. Credentials expire in that gap. Rate limits differ at 3am from when you queued.

The failure users actually notice is double-posting, and a naive retry produces it reliably. A send that times out has an unknown outcome, it may have succeeded on the platform and failed on the way back. Retrying assumes failure; not retrying assumes success. The only correct answer is per-platform idempotency, which means the queue holds enough state to check before re-sending. Draining after downtime is the related case: coming back after six hours and posting everything at once is worse than having dropped it.

Flask, with the scheduler in-process, which is the part I would change.