跳至主要内容
Post Array。中继
菜单

所有文章

代理运营

发布于 2026年8月10日

更新于 2026年8月10日

When half a multi platform post publishes

Partial success is the normal outcome of publishing to several platforms at once. Here is how to recover from it without publishing anything twice.

此文章尚未提供您的语言版本，正在显示英文版本。

作者：发布研究部审阅者：平台文档部

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.

Four states, and only one of them is simple

  • 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.

Unknown is a state, not a failure

The most expensive mistake is collapsing unknown into failed, because failed invites a retry. Record unknown as itself, resolve it by reading the platform rather than by writing to it, and only then decide.

Resolve an unknown by reading, never by writing

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.

What the platforms promise, and what they do not

Documented behaviour that decides how a retry can be written
What is documentedWhat it lets you do
LinkedIn states that post deletions are idempotent, and that deleting an already deleted post returns 204Cleanup after a partial failure is safe to repeat. Creation carries no equivalent promise, so the create path still needs your own guard.
LinkedIn documents a PUBLISH_FAILED lifecycle state and states that an edit is required before publishing is reattemptedA failed publish is not always retried by sending the same call again. Read the state first, and treat a failed state as work for a person.
Instagram separates container creation from publishing, and limits an account to 100 API published posts in a 24 hour moving periodA retry that recreates a container consumes the same ceiling as a real post. Reuse the container you already made rather than starting again.
X documents the create call as a single request with a reply object for chainsThere is no partial publish inside one call, but a chain of calls has as many failure points as it has links.

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.

The three pieces that make a retry safe

  1. A 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. A 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. A 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.

What to tell the person who was counting on it

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.

Never let a scheduled post silently disappear

A publication that ends in an unknown state and is then dropped from the queue is the worst outcome available, because nobody learns anything. Keep it, mark it, and require a person to close it.

来源