KamoCRM

The baseline award was two transactions, not one

FixSecurityService
Shipped
7 செப்டம்பர், 2026 அன்று 5:22 AM UTC
Author
Kamo
Commit
9d30f75

`ensureBaselineFor` calls `ensureBaseline` on `this`, and Spring's transaction advice is a PROXY — a self-invocation does not pass through it, so the inner REQUIRES_NEW never applied. Called from the controller, which holds no transaction, the award therefore ran with none: the state row and the unlock row each committed in their own implicit repository transaction. A failure between the two leaves a member holding an achievement they will never be told about — the cabinet says they have it and the queue has nothing to show them, which is the one inconsistency this feature's two-table shape exists to make impossible. Annotating the outer method is the whole fix. The inner call then joins that transaction, which makes the pair atomic and puts the afterCommit publish on the commit that actually matters. MemberCreationService was never affected: that is a cross-bean call, so the proxy applies and REQUIRES_NEW does what it says — a badge that cannot be written must not roll back the member who was just created.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing