The Idempotency Bug That Spammed dev.to's API for Weeks

This article was originally published on Jo4 Blog.

We built a small tool to keep our dev.to posts in sync with our markdown source files. Write locally, push to Git, and the tool updates dev.to if anything changed. Simple.

One morning, we noticed dev.to showing "Updated 2 hours ago" on an article we hadn't touched in weeks.

Then we checked the logs. Every article with an updatedAt field in its frontmatter was being republished. Every. Single. Day.

How the Sync Works

The tool is straightforward:

1. Read markdown posts with frontmatter (title, publishAfter, updatedAt, etc.)
2. For each post already on dev.to, check: "Has the local version changed since last sync?"
3. If isUpdateNeeded() returns true, PUT the latest content to dev.to's API

The check logic:

function isUpdateNeeded(localPost, devtoArticle) {
  // If local content changed after dev.to publish date, update needed
  const localDate = localPost.updatedAt || localPost.publishAfter;
  const devtoDate = devtoArticle.published_at;
  return new Date(localDate) > new Date(devtoDate);
}

Looks reasonable. If the local post was updated after it was published on dev.to, push the update.

The Bug

Here's a timeline of what actually happens:

1. Day 1: Post published with publishAfter: "2026-03-01", no updatedAt
2. Day 1 sync: Script creates article on dev.to. published_at = 2026-03-01T01:00:00Z
3. Day 5: We fix a typo. Set updatedAt: "2026-03-05" in frontmatter
4. Day 5 sync: isUpdateNeeded() → 2026-03-05 > 2026-03-01 → true. Updates dev.to. Correct.
5. Day 6 sync: isUpdateNeeded() → 2026-03-05 > 2026-03-01 → true. Updates dev.to again. Wrong.
6. Day 7 sync: Same thing. And Day 8. And Day 9. Forever.

The problem: updatedAt in the frontmatter is a static value. It doesn't change after Day 5. But published_at on dev.to reflects the original publish date, not the last update. So updatedAt > published_at is permanently true.

Every sync run thinks the article needs updating because the local update date is after the original publish date. It will never become false.

Why This Is an Idempotency Failure

An idempotent operation produces the same result whether you run it once or a hundred times. Our sync was not idempotent because:

• The comparison updatedAt > published_at doesn't account for "has this update already been pushed?"
• There's no record of "we already synced this version"
• The trigger condition never resets

This is the classic state management trap in automation: comparing a static input timestamp against a fixed reference point creates a permanently true condition.

The Fix

We needed the sync to know: "Have I already pushed this update?" The answer was to compare against dev.to's edited_at field (which reflects the last API update), not published_at:

function isUpdateNeeded(localPost, devtoArticle) {
  const localDate = localPost.updatedAt || localPost.publishAfter;
  // Compare against last edit, not original publish
  const devtoDate = devtoArticle.edited_at || devtoArticle.published_at;
  return new Date(localDate) > new Date(devtoDate);
}

Now the timeline works:

1. Day 5 sync: 2026-03-05 > 2026-03-01 → true. Updates dev.to. edited_at = 2026-03-05T01:00:00Z
2. Day 6 sync: 2026-03-05 > 2026-03-05 → false. No update. Done.

The second piece was handling the null propagation. When there's no update and we sync metadata, the script was using Object.assign() to merge frontmatter. But Object.assign skips undefined values — so when updatedAt wasn't set, the old value persisted instead of being cleared:

// Before: Object.assign ignores undefined, so stale updatedAt persists
const merged = Object.assign({}, defaults, frontmatter);

// After: explicitly handle null/undefined fields
const merged = { ...defaults, ...frontmatter };
if (!frontmatter.updatedAt) {
  delete merged.updatedAt;  // Don't carry forward stale dates
}

The Broader Lesson

Every automation system that syncs state between two systems needs to answer this question: "How do I know this sync already happened?"

Common patterns:

Approach	Pros	Cons
Compare timestamps (what we did, fixed)	Simple, no extra storage	Must compare correct timestamps
Store sync hash	Deterministic, content-based	Extra storage/state to manage
Idempotency key per sync	Guarantees exactly-once	Complex, needs key generation
Event sourcing	Full audit trail	Heavy for simple use cases

For content crossposting, timestamp comparison is the right level of complexity. You just need to compare against the right timestamp — the one that reflects "when was this last synced?" not "when was this first published?"

How We Caught It

Honestly? By accident. We noticed articles on dev.to showing "Updated recently" when we knew we hadn't changed them. A quick look at the sync logs confirmed it — the same articles being pushed on every run. The fix was five lines of logic. The debugging was thirty minutes of reading logs.

The embarrassment of silently spamming dev.to's API for weeks? Immeasurable.

Takeaways

• Idempotency isn't optional in automation. If your sync can run twice and produce different results (or the same unnecessary result), it's broken.
• Test your sync with unchanged content. Run your pipeline twice in a row. Does the second run do nothing? If not, you have a bug.
• published_at and edited_at are different things. Most APIs have both. Use the right one for your comparison.
• Object.assign doesn't propagate undefined. If you're merging objects where "missing" is meaningful state, handle it explicitly.
• Monitor your automation output, not just success/failure. Our script returned 200 every time. It was "succeeding" at doing unnecessary work.

---

Have you been bitten by an idempotency bug in your automation? What was the trigger? Drop it below.

Building jo4.io — a URL shortener with analytics, bio pages, and an affiliate marketplace for creators.