When a retry can publish twice

Your app sends an action to another service. The screen keeps spinning, then shows a timeout. Someone presses retry. The first request may already have worked.

For a social publishing job, the consequence can be two copies of the same post. Other apps face a similar question when sending a notification or creating a booking: did the action fail, or did only its response go missing? The example below concerns Tokenwise's own article distribution, not a claim that we have implemented those other integrations.

The problem: one job can have two different outcomes

Consider an illustrative failure: Facebook publishes an article, while Instagram's response is lost. A single red “failed” status hides a useful fact: one destination has already succeeded. Running both destinations again can duplicate that success.

Even the uncertain destination needs care. A timeout establishes that the caller did not receive a usable answer. It does not establish that the remote service rejected the action. An image-processing container is also different from a published Instagram post; saving the first identifier does not prove the second exists.

What the existing bridge records

Tokenwise's weekly article operator bridge wraps its existing Meta publisher. It gives each article occurrence a stable content key and stores a separate delivery record for Facebook and Instagram in Firestore. Each channel retains its own status, operation intent and available provider identifiers.

Before an allowed posting operation, the bridge checks the public article and exact committed JPEG. It saves the operation's intent in a database transaction before sending the request. After a readable response arrives, it saves the receipt immediately, including the Instagram container identifier when one is returned.

This order matters. A process can stop between sending a request and saving its answer. The earlier intent marker survives that gap and prevents the next invocation from assuming that no attempt happened.

The bridge also limits intercepted posting operations to Tokenwise's configured accounts. This is an operator tool for our own publishing workflow, not a general-purpose retry service.

Recovery starts with a read

On another invocation, a saved published-post identifier or publishing receipt is checked against the provider. The check requires the expected caption, published-image state and a permalink. If there is no usable published-post identifier, the bridge searches the configured account's feed for the exact authored caption within a bounded period.

One verified match can recover the result without another post. Multiple matches stop the operation for investigation. No match does not erase a previous attempt: if that channel has already entered publishing or an uncertain state, the bridge refuses a blind retry. Incomplete feed pagination also stops processing.

A channel with no prior attempt and no existing match can proceed. Each invocation handles one channel, so a problem on Instagram does not authorize another Facebook post.

What we checked—and what passed

On 15 October 2026, we ran the existing bridge tests locally with simulated provider responses and an in-memory state fixture. All five passed:

• A previously successful channel was reconciled without posting again while its sibling remained uncertain.
• A lost publishing response blocked a blind retry on a later invocation.
• Operation intent and a returned receipt were retained; a repeated posting operation was rejected.
• An unavailable exact image or an unrelated account prevented the intercepted Meta write.
• A matching prior feed post recovered an uncertain result without reposting.

These are focused checks of the delivery logic. They do not simulate every process crash, database failure or Meta response. The fixture injects provider checks; it does not exercise the live Graph API or Firestore transactions.

We also inspected the durable record of the previous weekly article, dated 12 October. It contains a verified Facebook post identifier and URL, a separate verified Instagram media identifier and URL, and a completed both-channel verification timestamp. That is a recorded successful occurrence. We did not use it to estimate a duplicate rate, claim uptime or infer time saved.

The deliberate limit: uncertainty can require an operator

This pattern does not guarantee exactly-once delivery. Firestore and Meta do not share one transaction. A feed can lag, a caption can be edited, or a provider read can fail. A saved Instagram container may need investigation even when no published media identifier was received.

The bridge therefore favours stopping over guessing. An unresolved attempt retains its receipts and container for bounded manual recovery. An operator must reconcile the evidence before authorizing any further write. A successful channel remains successful throughout that investigation.

The same separation applies to the release itself. Publishing an article on the website, posting it on Facebook and posting it on Instagram are three outcomes. Website deployment alone cannot establish social delivery. In Tokenwise's current daily release process, the coordinator verifies the approved article and image live before a linked, authorized social-only follow-up runs the existing publisher.

A question to bring to your next build

For every external action, decide what evidence will survive a missing response. Give each destination its own result. Record intent before writing, save the returned identifier, and make recovery inspect the existing outcome before considering another attempt. Where a provider offers its own idempotency mechanism, evaluate that too; local bookkeeping is not a substitute for understanding the provider's contract.

Want help defining reliable behaviour for an app idea? Describe your app on Tokenwise to start the project chat.

Source: Tokenwise's weekly article operator bridge and five existing delivery tests at factory-web revision bcdc5409823c9603e21c96a8bbc59bc5f6c1fe44, plus the dated prior publication record. This is an implementation lesson, separate from The Record's release chronology. AI-assisted text from verified factory code; AI-generated editorial illustration.