What makes a publishing failure safe to retry?
A publishing failure is safe to retry only when the destination probably did not accept the post and repeating the request cannot create a duplicate. Every failed publish should be classified as retryable, terminal, or unknown before any automatic retry starts.
A retryable failure is usually temporary: a connection ended before the destination received the request, a service was briefly unavailable, or a queue could not reach the destination. A terminal failure is a request that will not succeed without a change, such as invalid content, expired authorization, missing permission, or an unsupported destination feature. Repeating it wastes time and may consume a paid operation without changing the result.
An unknown outcome is different. The request may have reached the destination, but the publisher lacks a reliable answer. A timeout after submission belongs in this category, not in the retryable category. The safest next action is to reconcile the operation using a provider reference, an idempotency key, or a destination lookup where available. Only after reconciliation shows that no post exists should the system consider another publish attempt.
For more context, read How to Publish Social Posts Safely from an MCP Server.
Should a system retry before sending the publish request?
A system should retry preparation work only when the preparation step is independent, repeatable, and still valid when it runs again. Validation failures, missing credentials, and content-policy problems should stop before any publish request is sent.
Preparation can include rendering media, assembling a request, refreshing a short-lived authorization grant, or loading account settings. A temporary failure while reading configuration may be retryable. A failed content validation is not. Retrying a malformed request simply produces the same failure, while retrying an authorization refresh may be unsafe if the refresh process rotates credentials or invalidates an earlier token.
Keep preparation and publication as separate states in the job record. A job marked ready to publish has passed the checks that do not require a destination call. A job marked submitted must never be reset to ready merely because the response was slow. That state distinction prevents a worker restart from treating an already-sent operation as a new one.
Rules for authorization, media requirements, quotas, and supported features change over time. Builders should consult the relevant destination documentation before deciding which preparation failures can be repeated.
For more context, read What an AI Agent Needs Before It Can Post for You.
How many automatic retries should a publishing job receive?
A publishing job should have a small, explicit retry budget, a delay between attempts, and a clear handoff when the budget is exhausted. Unlimited retries turn one failing account into a permanent queue drain and can increase duplicate risk.
A practical policy separates quick recovery from prolonged recovery. The first retry can happen after a short delay, while later attempts wait longer. Add randomness to the delay so many jobs do not return to the same destination together. The exact schedule should reflect the operation cost, destination guidance, and the time value of the post, rather than copying a universal retry count.
Count attempts per destination operation, not per worker restart. Store the next eligible time and the reason for the last failure with the job. A restarted worker must continue the existing budget instead of granting a fresh set of attempts. Count only requests that actually reached the publish stage; do not spend the publishing budget on local validation errors.
Retry budgets should also have a wall-clock limit. A post intended for a narrow event window may become useless after a delay, even if the destination eventually recovers. At expiry, preserve the job and its evidence for review instead of silently discarding it.
What should happen when the publish result is unknown?
An unknown publish result should enter reconciliation, not an immediate second publish attempt. The system must first determine whether the destination accepted the original request or whether the request definitely stopped before acceptance.
Record the operation identifier, account, destination, content fingerprint, submission time, and response evidence before handing the job to a retry worker. A provider-generated operation reference is useful when the destination offers one. An idempotency key is stronger when the destination supports it, because repeated submissions can resolve to one operation instead of creating multiple posts. A content fingerprint is a local safety aid, not proof that two posts are the same.
Reconciliation can query an operation result, inspect a destination collection, or ask an operator to confirm the result. Each method has limits. A destination lookup may lag, omit deleted or restricted content, or return results without a stable match. If reconciliation cannot establish the outcome, keep the job in an explicit unknown state and expose it to an operator. Do not label it failed simply because no answer arrived.
A second publish becomes acceptable only when the evidence shows that the original operation was not accepted and the duplicate controls remain intact.
How can a retry avoid creating a duplicate post?
Duplicate prevention requires a stable operation identity that survives worker restarts, queue moves, and repeated requests. A new queue message must not automatically mean a new publishing operation.
Create one operation record when the user or automation requests publication. Give that operation a stable key derived from the job identity, destination account, and intended publication attempt. Reuse the same key for retries where the destination supports idempotency. Do not generate a fresh key inside each worker invocation, because the destination cannot connect the second request to the first one.
Where destination-side idempotency is unavailable, keep a local ledger containing the operation key, request fingerprint, submission state, provider reference, and any reconciliation result. Before retrying, compare the pending operation with the ledger. A matching accepted operation should end the job, even if the original worker never received a useful response. A matching unknown operation should wait for reconciliation rather than bypassing the ledger.
Content fingerprints help detect accidental repeats, but identical text or media does not prove that two intended posts are duplicates. The same content may be scheduled for different times or accounts. Include destination, account, and intended publication context in the identity, and make the duplicate rule explicit.
Which failures should stop retries immediately?
Retries should stop immediately when the cause requires a human, a changed request, or a changed account state. Continuing after a known terminal failure adds load without improving the result.
Stop for invalid or incomplete content, an expired or revoked authorization, missing permission, a destination feature that does not support the requested operation, and an account that cannot publish in its current state. Stop when the destination indicates that the request violates a content or policy rule. Stop when the post has already been accepted. An accepted post is a completed operation, even if a later metadata update fails.
The system should distinguish a blocked account from a busy destination. A destination-wide problem may justify delayed retries for many jobs. One account losing authorization should not repeatedly delay unrelated accounts. Store a human-readable reason, the affected account, and the action needed to resume. For credentials, ask for reconnection rather than repeatedly attempting the same authorization.
Rules affecting authorization, eligibility, content, quotas, and deadlines can change. Check the applicable platform documentation before encoding a permanent stop condition. Keep policy decisions separate from transport decisions so a temporary delivery issue is not mistaken for a content rejection.
How should retries work across many accounts and destinations?
Multi-account publishing needs isolated retry queues, per-destination pacing, and fair scheduling so one failing account cannot block every other account. A single global retry loop is simple to build and difficult to operate safely.
Partition work by destination account or by the smallest unit that needs separate authorization and pacing. A credential failure for one account should pause that account while jobs for other accounts continue. A destination-wide slowdown can reduce work for the affected destination without stopping unrelated destinations. The scheduler should consider each job's next eligible time, retry budget, publication deadline, and priority.
Use a circuit breaker for repeated failures at the account or destination level. When the breaker opens, stop creating more requests and record why. Recheck after a controlled delay, then allow a small amount of work to test recovery. A breaker is not a substitute for classifying failures. Terminal errors should still stop their own jobs, and unknown outcomes should still enter reconciliation.
Operators need a view of queued, retrying, unknown, completed, and permanently stopped jobs. Grouping by account reveals patterns that a single error total hides. PostWharf can use this distinction to help an operator find the one disconnected account without treating every scheduled post as broken.
How do you test a publishing retry policy safely?
A retry policy is ready for production only after tests prove that each failure class produces the intended next state and never creates an unplanned second operation. Test outcomes, not just individual functions.
Build a fault matrix covering a preparation failure, a request that definitely was not sent, a request with an accepted result, a request with an unknown result, a terminal rejection, a credential change, a worker crash, and a destination that recovers after delay. For each case, assert the stored state, retry count, next eligible time, operator message, and final number of publish operations. Include restarts between every important transition.
Test duplicate safety by delivering the same queue message repeatedly and by returning a timeout after the destination has accepted the request. The expected result is one operation record and one completed post, not two attempts with unrelated identities. Test two accounts at once to prove that one account's open circuit does not pause the other.
Use a sandbox or controlled test destination where possible, and inject failures before production traffic. Review logs for enough evidence to reconcile a job without exposing sensitive credentials or confusing internal diagnostics with an operator instruction. A retry system is trustworthy when its failure history explains what happened and what action comes next.
Sources consulted: Meta for Developers (developers.facebook.com) · LinkedIn Developer Platform (developer.linkedin.com) · TikTok for Developers (developers.tiktok.com)
Common questions
Should a timeout always trigger a retry?
No. A timeout means the publisher may not know whether the destination accepted the request. Treat it as an unknown outcome, reconcile it with an operation reference, idempotency key, or destination lookup, and retry only when evidence shows the original operation was not accepted.
What is the safest default for an unclassified publishing error?
The safest default is to stop automatic publication and mark the operation for review or reconciliation. An unclassified error may be temporary, terminal, or evidence of an accepted post. Blindly retrying can create duplicates, while a paused job preserves the information needed to decide.
Should every account share one retry counter?
No. Retry budgets should belong to the destination operation, with isolation by account where authorization, pacing, or account state differs. A shared counter can let one failing account consume the budget or attention intended for other accounts and can hide the actual source of repeated failures.
Can a content hash prevent duplicate social posts?
A content hash can flag likely repeats, but it cannot prove that a duplicate exists. Identical content may be intended for different accounts, destinations, or scheduled times. Use the hash alongside a stable operation identity, destination context, provider references, and reconciliation evidence.
Do platform retry rules stay the same?
No. Authorization behavior, quotas, deadlines, supported features, and error guidance can change. Check the relevant official developer documentation before hard-coding retry decisions, and design the policy so destination-specific rules can change without rewriting the whole publishing workflow.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.