← Back to blog

When a posting agent cannot tell whether it posted

A publishing attempt recorded as pending before sending, with an uncertain return receipt and a second message paused.

We saved the record too late. Our X posting agent wrote it after sending the whole thread, leaving a gap where X could accept the opening post and the process could stop before the next run had any record to check.

That empty record was enough to offer the same scheduled item again. The November 3 changes move the first write ahead of the first request, so an interrupted attempt leaves something the next run must respect.

The first write is now pending. It happens before sending. Each accepted post ID is saved before the next segment goes out. If a later segment is refused, the entry keeps the accepted IDs and becomes partial. A connection failure leaves it unknown; the next run refuses to post that item again until someone checks X and settles the record.

There was still a hole in the first version of this fix.

An HTTP 500 response followed the refusal branch, which could remove the entry when no post ID had come back. But a server error does not establish whether the platform created the post before returning that error. The follow-up change treats server errors, timeouts and a success response without a post ID as uncertain outcomes. It keeps the attempt on file.

I would keep the pause. Sending again could put the same message in front of followers twice, so we chose to block that item even though a temporary connection problem can leave it waiting for a person when nothing was published. Someone has to check X.

Mind map of unknown publishing outcomes: save pending before sending, preserve accepted post IDs and uncertain attempts, then pause and inspect the platform before retrying.

Medium needed the same change around its Publish button: save the attempt before clicking, then record the story after reading it back. If that readback fails, the article stays out of the automatic publishing queue until its result is checked.

The run log had a related bug. Its Medium filter expected a publication date, but an uncertain attempt only had an attempt date. We changed the filter to accept either, allowing those entries to appear as unconfirmed instead of disappearing from the list.

We have no outcome numbers yet. These implementation changes still leave someone with the job of inspecting the platform, recovering any accepted post IDs and settling the entry before the agent can move past an uncertain attempt, including one that never reached the platform.