I build a tool that schedules social posts. This week I added four new places to publish: WordPress, dev.to, Hashnode and Lemmy. Then I had each adapter reviewed by someone who did not write it. The most useful findings were all the same kind of bug: the code said "published" when it had only proven "the server answered". Here are four ways that happens. ## 1. A 200 is not the post My first version of the read-back check fetched the public page and treated HTTP 200 as "live". That passes for a maintenance page, a parked domain, a "coming soon" plugin, or a password-protected post whose public page is just a password form. All of them answer 200. The fix: read a small part of the page and require the post's title or its slug to appear in it. If the proof cannot name the post, it is not proof. ## 2. The URL in the response is not yours to trust The read-back used the link the platform sent back. On a blog with a custom domain, that domain is controlled by the customer. It can answer with a redirect to an address inside your own network, and a naive `fetch` follows it and reports success. The fix: do not follow redirects blindly. Check every hop, require the final host to match the expected host, and never send credentials past the first host. ## 3. A timeout does not mean "it did not happen" If the create request times out, the platform may still have created the post. A scheduler that retries now publishes it twice, in public. The fix: after a network error, look for a post with the same title from the last few minutes before you report a failure, and if you cannot tell, say so instead of retrying blindly. ## 4. "Saved as a draft" is not a failure Some customers choose to save a draft on the platform instead of publishing. A read-back that insists the post is public will call that a failure and retry it until it gives up. A draft that exists exactly where the customer asked for it is a finished job. It just should not be counted as published. The fix: give "saved as a draft" its own ending, so it is never retried and never inflates a "verified live" number. ## The pattern In all four, the code checked the easy thing (did the server answer?) instead of the thing I actually care about (can a stranger see this post?). Whenever a system reports success, ask what it actually observed, and whether that observation could be true while the post is not live. I use this idea in LazyRelay, the scheduler I am building: after every post it reads the platform back to confirm the post is really there. You can look at it at https://lazyrelay.com. What is the strangest "success" you have seen an API report?

A space to discuss and keep up software development and manage your software career

The 8 best Hashnode alternatives in 2026 for developer blogging. Compare features, code highlighting, custom domains, and developer community.

Think you need to be a senior dev to contribute? Discover how I tackled my first beginner-friendly issue, learned Git, and merged my first PR.

Discover the best blogging platforms in 2026. Compare Hashnode, WordPress.org, Blogger, Ghost, and Wix for SEO, AI search, customization, publishing, and growth.

Chrome Hearts clothing. Read the latest articles by chromehearts786 on Hashnode.

Golf Physical Therapy in Pittsburgh, PA. Read the latest articles by Dulak Golf Performance on Hashnode.

A blog about Quant UX Research, applications, topics, and careers. Features additional discussion related to the book "Quantitative User Experience Research" and the Quant UX Conference.

A blog powered by Hashnode

Hi, I'm Vishal Kushwaha I'm a Computer Science student passionate about Python, SQL, Data Analytics, Data Science, and Software Development. This blog is where I share beginner-friendly notes, practic...