Diagnose publishing incidents from the symptom first

Answer first: start from what the operator sees, freeze automatic retries, and separate local scheduling from the remote provider result. Confirm the intended identity and inspect the remote account before creating a replacement.

Capture a safe incident envelope

Record the local post/job identifier, provider, intended account label, scheduled timestamp and time zone, content format, last state, provider identifier if present, and timestamps for each transition. Keep access tokens, secrets, private messages, unpublished customer copy, and browser sessions out of tickets and screenshots.

Route by symptom

Symptom-first publishing incident triage

Symptom	Likely boundary	Safe next action
SymptomNothing appeared at the expected time	Likely boundaryTime zone, queue, worker, or provider rejection	Safe next actionConfirm UTC conversion, job state, and provider response before rescheduling
SymptomStatus is uncertain after timeout	Likely boundaryResponse lost after possible provider acceptance	Safe next actionOpen the remote account and query by provider ID; do not replay blindly
SymptomLocal status says failed but the post is live	Likely boundaryLate provider success or response lost after acceptance	Safe next actionMark failed-but-live, retain both timestamps, and suppress replacement
SymptomOnly part of a thread published	Likely boundarySequential mutation failed after earlier success	Safe next actionList remote parts, preserve IDs, then decide whether to complete or remove manually
SymptomDuplicate post	Likely boundaryRetry or two active schedulers	Safe next actionPause both schedules, retain IDs, remove only the approved duplicate
SymptomAuthorization error	Likely boundaryExpired grant, revoked role, or missing scope	Safe next actionConfirm account owner and role, then reconnect through the provider
SymptomMedia rejected or stuck processing	Likely boundaryFormat, size, codec, URL, or asynchronous processing	Safe next actionCompare the exact asset with current provider rules; wait only within the documented window
SymptomWrong account published	Likely boundaryIdentity selection or stale authorization	Safe next actionStop remaining jobs, notify the owner, remove only with authorization, and rebind identity
SymptomA successful post later disappears	Likely boundaryProvider moderation, author deletion, or policy enforcement	Safe next actionPreserve initial success evidence, record the later remote state, and alert the content owner

Distinguish retryable from unsafe

A rate limit with a Retry-After value is usually retryable at the stated time. A confirmed authentication failure needs a corrected grant, not repeated requests. Validation failures need new content or media. A connection reset or timeout after sending a create request is uncertain: the provider may have accepted it. Query status or inspect the remote identity first.

Threads are especially sensitive. X, Threads, Bluesky, and other reply chains may create parts sequentially. Earlier parts can be live when a later call fails. Treat “partial” as its own state and preserve the returned identifiers.

Use the native surface as independent evidence

The scheduler database proves what it intended and recorded. The worker log proves an attempt. The provider response proves what the API returned. The visible remote post proves what users can see. Keep these layers separate in the timeline; one does not substitute for another.

If a provider offers its own status endpoint, query it with the retained operation ID. For inbox-upload workflows, distinguish upload completion from the creator's later publication. For media containers, distinguish container creation and processing from the publish call.

Reconcile late success and partial targets

Model failed-but-live, partial, and moderated-after-success explicitly. A late success must close the replacement path and notify the incident owner before another copy is created. For a multi-target post, retain one result per provider account; retry only the confirmed failed target, never the entire source batch.

An alert should identify the workspace, intended account label, local item ID, target state, scheduled time and zone, and next safe action. It must not contain tokens or unpublished copy. Route uncertain and wrong-account outcomes to a human immediately; routine retryable rate limits can remain in an operational queue with their documented next attempt.

When diagnosing duplicates, trace every possible source: two active schedulers, a manual native post, a webhook consumer, an agent/API caller, a migration replay, or a user clicking retry after a slow response. Match source IDs and timestamps before deleting anything. Two visually identical posts do not prove which one is the duplicate.

A Naasher worked example

Naasher uses bounded retry behavior around provider mutations and leaves uncertain outcomes for verification instead of automatically replaying them. An operator should open the target network, compare provider IDs, and decide whether to complete, cancel, or replace the post. TikTok SEND_TO_USER_INBOX is a handoff, not public publication. An X thread can be partial because each reply depends on the previous returned post ID.

Close the incident with prevention

• Revoke stale credentials and remove former staff access.
• Add the failed format to the acceptance matrix.
• Keep only one active scheduler during migration.
• Show account identity, time zone, and format at approval.
• Preserve provider IDs in operational history.
• Test a known failure case before trusting automatic recovery.

Close only when the remote state matches the decision, future jobs are safe, and the prevention owner is named. “The retry passed” is not enough if the first mutation may still exist.