A scheduled message needs one owner before it sends

I contributed to Atlas's Slack messaging workflow across composition, formatting, scheduling, rotations and delivery fixes. The consequential problem was easy to miss from the composer: two workers can read the same due message before either records that it sent.

Editing a schedule can create a second record too. These are different sources of duplicates, and my fixes addressed them at different boundaries.

Claim the record before calling Slack

The authored change added a transactional claim inside the scheduled-message processor. The worker rereads the document in a Firestore transaction. Deleted records and records outside pending or recurring status are skipped. A successful claim changes the status to sending before the Slack call.

That makes the database decision visible to another worker.

The processor then records sent or completed status, or advances the next occurrence for recurring messages. Failed sends move to failed status. The scheduled-message listing includes sending, so a claimed message does not disappear simply because processing began.

I would describe this as concurrency control around a send, not exactly-once delivery. Firestore and Slack do not participate in a shared transaction. If Slack accepts a message and the process dies before final persistence, the database alone cannot prove what happened. The inspected change has no expiring lease or automated reconciliation for a stranded sending record.

Inspect the system diagram

Open full-size SVG →Horizontal version →

A rotation has another form of state

The authored change applies a transaction to rotations. It compares the stored last-processed date with the current date in the configured timezone, then claims the day by writing a timestamp. Another processor sees that claim and skips the rotation.

Dry runs avoid that write.

The inspected dry-run branch chooses a nudge and reports what it would send while bypassing the claim and transport. A preview that claims today's rotation could suppress the real message later.

This does not establish that every helper it calls is free of other state changes.

I also added an environment boundary on automated cron requests. A non-production cron returns a skipped result; authenticated manual requests can still trigger testing. This reduces one source of duplicate processing across copied environments, but it is not a blanket prohibition on non-production sends.

The rollback behavior deserves a careful explanation. When transport returns an explicit failed result, the rotation restores its prior last-processed value. A thrown exception after claiming follows the outer error path instead. The claim can remain. A missing nudge after the claim has the same suppression risk. Neither branch supports a claim of automatic recovery from every failure.

I want an interviewer to see that distinction in my reasoning.

Fixing editing at the point of intent

The composer change in the authored change selects PUT when an editing-message ID exists and includes that ID in the request. New schedules still use POST. The success message also distinguishes an update from a new schedule.

That is a small change with a concrete operator consequence: editing an existing record should update its identity rather than create a second due message. It complements delivery claims; it does not replace them.

Earlier contributions include Markdown-to-Slack formatting, attachment and submit fixes, service and hook decomposition, notification-surface registration and nudge composition. The coverage matrix retains those records. I do not count each refactor as an independently delivered messaging system.

Reconstructed duplicate-send walkthrough

1. Use invented message rotation-harbor-01 and fictional Slack destination team-ops.
2. Let two workers read the same pending record. Show one transaction claiming it and the other skipping after its fresh read.
3. Show the provider call and the later completion write as separate steps.
4. Reconstruct a process interruption between those steps. Leave the outcome unresolved rather than replaying it as a confirmed failure.
5. Preview a rotation without changing its day claim. Then contrast an explicit failed send, which restores the claim, with an exception, which may leave it claimed.
6. Edit the existing schedule and show PUT with the original ID.

This sequence illustrates the inspected branches. It is not a recorded incident or a production send.

Results and interview use

My merged changes establish claim-before-send behavior, a cron environment gate and edit-versus-create request selection. The available evidence does not establish the number of duplicates prevented, incident frequency or current operator use. Those outcomes would require delivery logs and incident records.