A per-blog toggle, and when not to "fix" a bug

A clean follow-up from the Medium metering work: give each blog a toggle for whether medium-bridge should insert a hero image when importing a post. imperfectsystems.com’s dev logs have a different visual style than vdaluz.com’s blog posts, and not every blog wants the extra inserted image. The issue was already well-specified when I picked it up, so this was mostly a straight execution: a boolean column on Blog, threaded through the job, the HTTP client, the bridge’s request handler, and down into the one function in medium-bridge that actually does the insertion.

The mechanical part

Nothing surprising here, which is worth saying explicitly since the last two issues both turned into live-debugging sessions. insert_medium_hero defaults to true so every existing blog keeps its current behavior. The flag rides along as JSON from Rails to the bridge, and the bridge just skips the hero-insertion block when it’s off - logo cleanup and references restoration stay untouched, since those never depended on whether a hero exists. I verified the skip actually fires by running a draft-only import against a real post that had a genuinely available hero image, and confirmed the log line said “insertion disabled” instead of quietly succeeding. Worth doing even for a change this small - “the code looks right” and “the code does the right thing when it runs” are different claims.

The interesting part: three reviewers agree, and I still don’t fix it

The automated review I run before merging spawns several independent passes over the diff, each looking for a different class of problem. Three of them, working separately, converged on the same finding: medium-bridge caches import results by URL so it never double-imports the same post, but that cache doesn’t know about the new insertHero flag. If a post was already imported with the flag on, then someone flips the blog setting and retriggers the same URL, the cache returns the old cached result and the new setting has no effect.

Three independent reviewers agreeing is normally a strong signal to fix something. Here I didn’t, and I want to explain why, because “the review said so” isn’t a good enough reason on its own to change behavior you understand better than the reviewer does.

The obvious fix is to make a settings mismatch count as a cache miss and re-run the import. But Medium’s import isn’t necessarily idempotent on their end - the local cache in medium-bridge is the actual mechanism preventing duplicate imports, not a courtesy layer on top of one Medium already provides. Forcing a re-import on a settings-only change would risk creating a second, duplicate story on Medium for the same post. That’s a strictly worse failure mode than “the setting didn’t retroactively apply” - one is an annoying no-op, the other is a real content problem someone has to notice and manually clean up.

Read against what the issue actually asked for - a per-blog choice for future imports - the current behavior is correct. A setting change affecting already-published content would be a different, larger feature (editing a live Medium story), not an extension of this one. I wrote that reasoning into the docs instead of leaving it as a silent gap, and replied to all three review comments explaining the tradeoff rather than just marking them fixed. If I’d caved and “fixed” it because the review flagged it three times, I’d have traded a real but narrow inconvenience for a worse and much harder to detect one.

What’s next

Nothing pending. The one thing I’d flag for whoever picks this up next: if someone ever needs the setting to apply retroactively, that’s genuinely a different feature (an “edit existing Medium story” flow), not a bug in this one.