fix: defer ClientCreationEvent to after transaction commit [fj4WqyCCw3C5ShR1RfB7MoBPTpkRrBFYP1uT35g3MvT] - #51598

Thanks for picking this up — issue reporter here. Deferring the publish past client population is the right instinct, but I think enlistAfterCompletion overshoots: it moves the event to after the main JPA transaction has committed, and the primary consumer this issue is about writes to the database when it receives the event.

The path: WorkflowEventListener.onEvent(ProviderEvent) → DefaultWorkflowProvider.submit(...) → activation → JpaWorkflowStateProvider, which does em.persist(...) for new WORKFLOW_STATE rows and criteria executeUpdate() deletes for restart/cancel handling — all through the session's EntityManager, relying on the surrounding transaction to flush. In DefaultKeycloakTransactionManager.commit() the order is prepare → transactions (which includes the JPA transaction) → afterCompletion, so by the time this callback publishes the event the JPA transaction is already committed: the em.persist lands in a persistence context that will never flush again (activation silently lost), and the executeUpdate() paths throw TransactionRequiredException. The condition would now evaluate against a fully populated client, but the resulting state write is lost — the workflow still never activates, just one step further down the chain.

enlistPrepare seems like the right hook instead: prepare transactions commit first, while the JPA transaction is still active. At that point the caller (e.g. RepresentationToModel.createClient) has long since applied attributes/redirect URIs/mappers — population happens during the request, and only the publish needs to move to commit time — so conditions see the complete client and listener writes still flush with the main commit. It also keeps the current semantics that the event is part of the creating transaction (a listener failure can still roll back the creation, and nothing observes a committed client that later disappears), which afterCompletion silently changes for every ClientCreationEvent subscriber, not just workflows.

Two smaller notes:

• The rollback story with enlistPrepare stays trivial: if the request rolls back before commit, the publish never runs; no need for the no-op KeycloakTransaction scaffolding.
• Whichever hook wins, a regression test that creates a client matching an on: client-created workflow condition and asserts the WORKFLOW_STATE row exists after the request completes would catch exactly this class of bug — condition evaluation and state persistence have to be verified together.