Graph API error (#613) Curl failed: Operation timed out — distinguishing timeout from successful post creation

Handling Graph API publish timeouts without duplicating posts

When a POST to /{user-id}/feed exceeds the client timeout, Facebook returns (#613) Curl failed: Operation timed out after ... milliseconds. The API does not provide an idempotency key for publish operations, so a naive retry after this error can create a duplicate post if the original request eventually succeeded on Facebook's side.

Client‑side cancellation (aborting the HTTP request) surfaces the same error code and message, making it impossible to differentiate a true network timeout from a deliberate abort. Facebook's guidance is to inspect the error code and message, then avoid retrying unless the application can tolerate duplicates or implements its own deduplication strategy.

Open questions

• What reliable pattern can detect whether a post was actually created before the timeout error was returned?
• Is there a safe way to correlate a timed‑out request with a subsequent post ID using only the Graph API?
• How should a server‑side integration log or flag these ambiguous timeout responses for later reconciliation?