[Silthus]

Part of the code-first rebuild of the email send stack; replaces parts of PostHog#121867 (the workflow reload it needs, split out to land first).

Problem

• Saving a workflow tells the CDP workers to reload it before the save commits. A worker that reloads in that window reads the old row and keeps running the old version until its cache expires.
• That hits every workflow save inside a transaction: the editor, publish, revision restore, proposals and transactional email templates. A paused or edited workflow can keep running as it was.
• The email send stack depends on it. feat(cdp): replay a keyed send after its workflow or default sender changes #580 checks a workflow's active status in cdp-api, and feat(messaging): send each email once per idempotency key #578 relies on that check, so both land after this PR.

Impact

Pays into Grow Workflows: an edit or a pause takes effect on the workers as soon as it commits. In scope: Workflows, every workflow save.

Merge Danger

Warning

🟡 Merge risk: medium · two-way door: a revert brings back the reload before commit

• Not behind a flag. Every workflow save now reloads the CDP workers after its transaction commits, not before it.
• A save inside an outer transaction reloads at the outer commit. A save in autocommit reloads at once, as before.
• A failed reload publish no longer fails the save, and no longer skips the commit callbacks after it.
• Rebasing feat(workflows): show code-managed email templates read-only #575 to feat(messaging): send each email once per idempotency key #578 onto this PR conflicts in transactional_email.py and in the tests that patch its reload. Those tests drop that patch.

Changes

Kind	Files	Lines
Production	3	+9 −24
Tests	3	+55 −19

• A saved workflow reloads on the workers once the save commits. hog_flow_saved publishes the reload in transaction.on_commit(..., robust=True).
• hog_flow_deleted already published after commit, and is now robust=True too.
• The separate after-commit reload in sync_transactional_workflow is gone, because the save now covers it.
• Mechanical: the comment on the pause writer's queryset update now gives the reason that still holds.

Saves that now reload at the outer commit, from transaction.atomic blocks on master:

• services/hog_flow_writes.py: create, update, edit content, and publish a draft. A save that changes only draft and draft_updated_at never reloads.
• services/hog_flow_revisions.py (restore) and services/workflow_proposals.py (apply).
• Transactional email workflows and message template updates (sync_transactional_workflow).
• The refresh_hog_flows, migrate_hog_flow_secret_inputs and strip_placeholder_sender_overrides commands.

The pause and resume writers and refresh_affected_hog_flows publish their own reload after commit, and do not change.

How did you test this code?

Test seams: the post_save and post_delete receivers (test_hog_flow.py), the transactional template PATCH endpoint (test_transactional_email.py), and the refresh_hog_flows command (test_refresh_hog_flows.py). Each runs the commit callbacks with captureOnCommitCallbacks(execute=True).

Test rationale, run red against master first:

• An email pause save whose reload runs before the commit.
• A transactional template update whose reload runs inside its transaction.
• A failed reload publish, on save and on delete, that fails the save or skips the commit callbacks after it.

Proofs:

• Live run on a local stack: Django at this head, cdp-api and the CDP workers at master, on data that master wrote first (saved with fleet proof). Each send runs about 3 ms after its save answers.

Case	Save	Send	Delivered
Template update, three subjects in a row	200	202	Each email has the subject just saved
Workflow update, three subjects in a row	200	202	Each email has the subject just saved
Workflow set to draft, then archived	200	400 transactional_email_paused	Nothing
Workflow set active again, after each	200	202	Yes

• Worker logs: each save gives exactly one reload on each worker and on cdp-api, and it arrives before the save answers. On master the same save gives two: one before the commit and one after it.
• Prod shape: a gap until read-only production access exists on 2026-11-02.

CI: the fork has no Depot runners, so those jobs never start, and no secret for the project-board app, so flags-project-board fails; the other GitHub-hosted checks pass. The lane check passes: the PR changes only the Python side.

Release status

• No feature flag controls this change

Docs update

None.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Agent: Claude Code, Claude Opus 5.5 (claude-opus-5-5)

• Built as lane srv2 of map Map: send code-managed email templates with one PostHog call #461. It was part of feat(messaging): send each email once per idempotency key #578 and moves here unchanged, minus the edits to test files that are not on master.
• Skills: tdd, writing-tests, pr-description, writing-pr-descriptions.

Question	Answer	Who	Where
Does the reload-after-commit fix land inside #578 or on its own?	On its own, off master, landing before #580 and #578	👤 Human	map #461, 2026-10-25
May the code carry comments?	No; names carry the reasons	👤 Human	map #461, 2026-10-25

Involvement: one decision from Michael; reviewed inside #578 in two rounds (GPT-6.1 Sol, Opus fresh eyes).

🤖 Generated with Claude Code

[github-actions]

🤖 CI report

⚠️ Comment density — 5% of added code lines are comments (4 of 79)

This section warns when comments are more than 3% of the code lines a PR adds, and alerts above 6%. Before agent-assisted PRs, the typical share was about 2%. Only full-line comments count. Docstrings, generated files, snapshots, migrations, and workflow files are left out.

Comments that restate the code, record how the change came about, or narrate the next line add noise for the next reader. Keep the comments that explain a reason the code cannot show, and remove the rest. See .agents/skills/writing-code-comments/SKILL.md for the house rules.

Files with the most added comment lines:

File	Comment lines	Added lines
products/workflows/backend/services/workflow_email_health.py	4	4

This check does not block merging. It updates on every push and clears when the share drops.