Skip to content

[WHIT-3592] Enqueue role publishing jobs from after_commit#11565

Open
TonyGDS wants to merge 1 commit into
mainfrom
fix-cabinet-minister-publish-race
Open

[WHIT-3592] Enqueue role publishing jobs from after_commit#11565
TonyGDS wants to merge 1 commit into
mainfrom
fix-cabinet-minister-publish-race

Conversation

@TonyGDS

@TonyGDS TonyGDS commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

What

Move the Publishing API republish callbacks on Role, RoleAppointment, Person and MinisterialRole from after_save/after_update/after_destroy to after_commit.

Why

A new cabinet minister appeared under Departmental ministers but not Cabinet ministers on the live Ministers page until an editor manually re-ordered the list.

The Cabinet ministers section is rebuilt from a single PatchLinkSet on the ministers_index content item, derived from live appointment data. That patch was enqueued from an after_save callback, which runs inside the DB transaction. Publishing API event logs confirmed the appointment committed at 20:06:52 UTC and the PatchLinkSet at that same second rebuilt the list of 21 ministers without the new appointment — the Sidekiq worker read the row before the transaction committed. Nothing re-patched until the manual re-order. The Departmental section was unaffected because it is rebuilt by a full Organisation republish triggered from several paths.

Fix

Enqueue these jobs from after_commit so they only run once the change is durably committed and any worker is guaranteed to read it. No change to the payloads sent; only the timing and the failure semantics (a failed enqueue no longer rolls back the editorial save — consistent with Organisation's existing after_save_commit).

The Ministers page Cabinet ministers section, and related published
pages, are rebuilt from live role and appointment data whenever a role,
role appointment, person or ministerial role changes. These republish
jobs were enqueued from after_save/after_update/after_destroy callbacks
that run inside the database transaction, so a Sidekiq worker could pick
the job up before the transaction committed and republish pre-commit
data, dropping the very change that triggered it.

Move the callbacks to after_commit so the jobs are enqueued only once the
change is durably committed and any worker is guaranteed to read it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant