Two copies of my posting job ran at once. One video went out twice.

My videos get cut, captioned and scheduled by a job that runs on its own, usually at night. It picks the next hook for a piece of footage, gives the new video a name, renders it and sends it to the scheduling tool. One job at a time, one name each. That was the assumption.

On August 16th two runs overlapped. Both asked the system what the next name was, both got the same answer, and both went ahead. Two runs, one name, and one video pushed live twice. My records only knew about one of them, so nothing on my side showed a problem. It happened a second time the same day.

The cause was a gap in time. The name was handed out when a run asked for it, but only taken minutes later, when the video finished rendering. Anyone asking inside that window got the same number. Every single step was correct. The failure lived between the steps.

The fix was to make taking the name happen at the moment of asking. A run now reserves its name in the database before it renders anything, and the database itself refuses to give the same name out twice. If two runs ask at once, one gets it and the other is told to pick the next. A reservation that is never used expires after 30 minutes, so a run that crashes cannot lock a name forever.

If you run anything on a schedule in your business, this is worth a look. Two people, or two automations, working from the same list will sooner or later grab the same item. Reading a list and claiming an item have to be one step, not two.

A quick check: start the same job twice at the same moment and see what happens. If the answer is “I don’t know,” the duplicate is already waiting for you.