When half a multi platform post publishes

One idea sent to five destinations is five independent publications. Four of them can succeed while the fifth times out, and that is not an edge case. It is the ordinary weather of publishing across platforms, and a process that has no answer for it will eventually resolve it by publishing something twice.

This article is about the hour after that happens: what the states actually are, which ones are recoverable, and how to retry without turning one post into two.

• Accepted and confirmed. The platform returned an identifier. This is the only state where you know what the reader sees.
• Refused. The platform returned an error before doing anything. Nothing exists, and a retry is safe once the cause is fixed.
• Unknown. The call timed out, or the connection dropped after the request was sent. The platform may have done the work. A blind retry here is how duplicates are born.
• Accepted and still processing. The platform took the work and has not finished it. Instagram documents this explicitly for video: create a container, then query its status, which its own guidance suggests doing once per minute for no more than five minutes before publishing.

The safe recovery for an unknown is a read against the platform for what exists on that account, using an identifier or a marker you controlled before the call. LinkedIn, for example, documents retrieving posts by author with a sort by creation or last modified time, which is exactly the read you need to answer whether your post landed.

That read has to be paired with something recognizable in the post itself. Time is not enough on a busy account, and neither is the opening line if the same line runs on several destinations. A durable local record of the attempt, with the exact text sent and the timestamp of the request, is what makes the read conclusive.

Notice the shape of that table. Deletion is idempotent in one place, publishing is a two step process in another, and nowhere is creation promised to be safe to repeat. Publish once semantics are something you build, not something you are given.

1. 01A key you generate before the first call and reuse for every retry of that same intent, so your own system can recognise a repeat even when the platform cannot.
2. 02A record written before the call, not after it. A record written only on success cannot describe the case where the process died between the request and the response.
3. 03A read path that can answer, for one account and one attempt, whether the work exists on the platform. Without this, every unknown ends in a human opening the account and looking.

None of that is exotic, and all of it has to exist before the first partial failure rather than after it. The reason to build it early is not elegance. It is that the alternative, under time pressure, is somebody clicking retry.

The operational half of partial success is communication. A status that says failed when three of five destinations published is a lie that costs somebody a morning. The honest report names each destination, its state, and the platform identifier where there is one.

It also has to distinguish what a retry would do. Retrying two failed destinations is not the same action as republishing everything, and a person under pressure will pick whichever button is larger. Make the safe action the obvious one.

See what is recorded per platform, and what is not built yet