@mposolda - might be a good idea to mark issue #21514 to be backported to KC22 once this is merged, leaving the decision to you as it is core releated.

@mposolda looks great, thanks for all the changes.

One small question though: shouldn't the whole registration flow run in one transaction? If an Exception happens in any "step" (either builtin or custom flow step) of them is it a correct state that we end in? Is there any way to handle rollbacks then?

@ahus1 Thanks! Would you please mind to approve if it looks good to you?

@vilmosnagy The default registration flow runs in one transaction by default after click "Register" button AFAIK. Or more accurately, I think that it works like this:

• When the user clicks Register on login screen and the registration form is shown, there is call to buildPage for all FormAction steps under the registration form top subflow. This all happens in one transaction
• When user fills the form and clicks Register button, there is another transaction where all the validate and success steps of all FormAction are triggered.

So typically, there is one transaction for each HTTP request.

It is possible to re-configure registration flow to involve multiple transactions if administrator decides to add multiple steps under top flow (EG. if he wants something like "wizard" of multiple steps for registering user) and in this case it could be multiple transactions.

I think that throwing AuthenticationFlowException doesn't mean rollback of transaction, which is likely also why the user was created in DB. As a follow-up, we can consider throwing an AuthenticationFlowException to also do transaction rollback though, however I am not yet sure about all the side-effects on this, so it currently doesn't work this way. Especially during normal authentication, there are also updates to authenticationSession and we need to make sure that those are not lost. In other words, even if some step in the authentication flow is not successful - like for instance user failed to add proper username/password - the authenticationSession may still need to be updated in the particular HTTP request.)

I think that throwing AuthenticationFlowException doesn't mean rollback of transaction, which is likely also why the user was created in DB.

Thanks, that answer's all my questions.