Stress Test — Cross-post Article

Why cross-posting is the hardest branch

Cross-posting sits at the intersection of the pipeline and three external services that each have their own error personalities. Dev.to can return 4xx for malformed markdown. Todoist can throttle. Slack can accept the message and silently not render. None of those failure modes shows up in the WordPress side of the pipeline, so editors assume everything worked.

This article is the trigger for T9 (production cross-post), T10 (resync blocks second cross-post), and T11 (conversation does not cross-post because content type is not article). Setting Environment to Production and flipping Status to publish fires T9. Flipping Status back to resync fires T10. Creating a conversation with Environment to Production fires T11.

What success looks like

T9: Dev.to article exists at a stable slug, Todoist task exists with a Dev.to URL in its description, Slack is silent, Notion Last Error stays empty. T10: WordPress post is patched, no second Dev.to post is created, no second Todoist task is created. T11: no Dev.to or Todoist activity at all.

What to watch

The Cross-post Gate If node on VPS currently uses a single condition isProduction === true. That is correct but fragile. If anyone re-adds the $env.ENABLE_CROSSPOST condition, cross-posts will silently fail on community n8n because $env returns undefined. The fix from Session 8b is a permanent one; do not reintroduce $env.

Also watch the Write Success to Notion to Cross-post Gate handoff. Session 8b found that HTTP Request responses overwrite $json, so downstream nodes must use $('Prepare Writeback').first().json.X back-references. Any new contributor who edits these nodes without knowing that rule will break cross-posting silently.