What happens if it runs twice

Assume the second run

What a second run breaks

The expensive version is the double send. The customer gets two review requests, the vendor gets the same purchase order twice, the past-due notice goes out again to someone who paid yesterday. This is the one people picture, and it is the one that costs trust rather than time.

The double row happens more often. Whatever file feeds your numbers picks up two entries for the same invoice or the same job, and now every count and every average built on it is wrong. We have hit this on our own metrics files, including two rows carrying the same identifier, and the damage is that nothing looks broken. A wrong average reads exactly like a right one.

The overwrite is the one people miss. The second run writes over what the first run produced. No error, no duplicate, just work that existed at 3:05 and does not exist at 7:05. You find out later, usually when someone goes looking for a file they remember seeing.

Key it to the item

The fix is a key. Pick the field that identifies one piece of work, check it before acting, and record it after. Invoice number. Work order number. The message ID of the email. Customer plus job number if nothing better exists. If the key was already handled, the job stops instead of sending.

Two details decide whether the key actually protects you.

• Check immediately before the send, not at the top of the run. A run that starts at 7:00 and sends at 7:04 has four minutes in which the other copy can beat it there.
• Never key on the date. We had a queue keyed on the day something was scheduled for, which meant it accepted one item per day and dropped the rest with no error. Keying on the date is a promise that you will never do two of these in one day, and that promise expires the first busy week.

Append, do not overwrite

There are two ways to record what an automation did, and most setups need both. One file per job holding the latest status, rewritten every run. One log where every run appends a line and nothing is ever edited.

The status folder here holds 62 files, one per job name, and the last run wins. That answers whether a job ran today and tells you nothing about Tuesday. The append log is what actually holds the history, which is why it is worth being careful with. On August 17 ours got wiped down to a single line, and the run count above starts on August 9 because that is as far back as we could rebuild it from saved output.

So the rule for anything you will want to count later: append it, timestamp it, and let the duplicates land. Deduplicate when you read, not when you write. A log with an extra row in it can be cleaned up. A log that was rewritten cannot be un-rewritten.

The question to ask whoever builds it

Ask what the key is. A good answer names a field: it checks the invoice number against what it already sent. A weak answer is some version of it will not run twice, which is a prediction about servers, laptops, and people, and it is wrong within the year.

The cheap test is to run the thing by hand twice against the same input and read what came out of the second pass, right after you have replayed it against real history the way dry run it against last month describes. Two minutes of work. It is how you find out that the send flag protects the email but not the text message, or that the file gets its name from the date instead of the item.

None of this shows up in a demo. It shows up in month four, on the morning the machine was off overnight and everything catches up at once, which is the same territory as why automations fail silently. Watching for it after launch is most of what the managed service actually is.