The 5 Edge Cases That Broke Our Dev.to Auto-Crossposting (And How We Fixed Them)

This article was originally published on Jo4 Blog . In our previous post , we covered the producer-consumer problem for blog scheduling. But we glossed over the crossposting part. "Just POST to the dev.to API," we said. "How hard could it be?" Narrator: It was hard. The Setup We have a Node.js script that runs daily via GitHub Actions: // Simplified flow 1 . Find all markdown posts with publishAfter <= today 2 . Check if they exist on dev . to already 3 . If not , create them 4 . Send Slack notification Sounds straightforward. Here are the edge cases that broke it. Edge Case 1: How Do You Know If a Post Already Exists? The Problem We can't just check our local database—we don't have one. The blog is a static site. So how do we avoid posting duplicates? Naive approach: Keep a .crossposted.json file locally. Why it fails: Someone manually posts to dev.to. Someone deletes the JSON file. Someone runs the script from a different machine. Duplicates everywhere. The Fix: dev.to Is the Source