A forty-line guard removes the second writer behind a double-posted announcement

The reservation mark worked as designed: a row carrying a dev.to article id means the work is done ^[8]. The problem was where that row lived. The local run wrote it at 07:46 UTC and the push did not happen until 09:25, so for 99 minutes the only copy was on one machine's disk ^[7][9][24]. The retry cron's read landed 42 minutes before that push ^[25].

The second writer was there on purpose. GitHub's cron does not fire on time under load, and on some days theirs ran two to four and a half hours late ^[5]. The health check, as written, advised the agent to run the same CLI locally when an announcement was missing, and the agent followed the advice ^[6]. The write-up's summary of the result: "The idempotency key was correct. It was just sitting in a state that only one writer could see." ^[11]

The evening commit made the platforms authoritative: before creating an article, the publisher fetches the account's full list, drafts and scheduled included, and refuses on a title match ^[12]. If the Bluesky lookup itself fails, the CLI does not post ^[14]. The stated reason is that "Leaving the announcement for the next run is cheaper than a possible duplicate" ^[15].

Read-then-write has a window. Between the read and the write sit the round trip to Bluesky and however long a new post takes to appear in the author feed. Two writers inside that window both read an empty feed and both post ^[16]. A reader of the original incident write-up argued that when the write side offers no conditional write, the read should not be treated as authoritative. The alternative that reader offered was to make duplicates visible and reversible ^[17].

That suggestion went into the ledger as a deferred item with a plan: re-search the feed after posting, delete all but the oldest copy, record each deletion in the post log, and expose the detected-duplicate count in the health check ^[18]. The delete call already existed in the Bluesky client ^[19]. The ledger also recorded a recurrence count of zero since the read-before-write check went in ^[20]. The recorded impact was one duplicate sitting on the timeline until a human removes it, in a window measured in seconds to tens of seconds, on a job that runs a couple of times a day ^[21].

For that zero to transfer, the firing rate has to transfer. A path that runs per event enters the same seconds-wide window many times an hour, and the reaper would remove duplicates the guard cannot prevent.

The guard tests one environment variable, and it runs before any side effect in the CLI. It returns when GITHUB_ACTIONS is 'true'. Otherwise it throws an error, written in Japanese, telling the operator to start the workflow with gh workflow run and wait on it with gh run watch ^[22][23]. What it removes is one writer, the local session. Both crons, the 02:17 primary and the 08:33 retry, run inside Actions and pass its only test ^[4]. The write-up does not describe a concurrency control that would keep a badly delayed primary run from overlapping the retry ^[27].