Automatic confirmation of a registration prone to fail

[hannesbochmann]

Extension version

5.9.2

Short problem description

The automatic confirmation is done through a redirect to the appropriate action. If a user cancels the redirect (for example the redirect takes some time and the browser window is closed meanwhile or another link is clicked) or a error happens after the redirect but before the action could be called, the registration will stay unconfirmed. As no mails are sent in this case the registration might not get noticed by anybody and perish.

Steps to reproduce

1. Register for a event.
2. Cancel the redirect.

Expected behaviour

A registration with automatic confirmation should be confirmed in every case.

Actual behaviour

A registration with automatic confirmation is not confirmed in every case.

Server configuration

TYPO3 version: 10.4

PHP version: 7.4

I propose to use a forward() instead of a redirect() to trigger the automatic confirmation.

[derhansen]

Thanks for your message. I checked the scenario carefully but do not really see a problem with the redirect for the automatic confirmation.

1. User cancels the redirect = not something the extension can do about. Different example: If a user e.g. cancels a payment on Paypal (e.g. closes window, is impatient and clicks other link), it is the users fault that the payment is not processed.

2. Redirect takes too long - Basically, also for uncached TYPO3 actions, this should take so much time, that the user has enough time to cancel the request. If the request is really slow (several seconds), this may be an issue with the webserver (too less resources). I do not see any problem with redirects here and also TYPO3 core uses redirects in several places (e.g. ext:felogin) like ext:sf_event_mgt does.

3. An error happens - what error exactly? An exception - from where is that generated? Maybe in case of an TYPO3 error due to a system failure? No idea how to catch such errors in the extension itself and a forward will also not do anything different, if an error occured.

Changing from a redirect to a forward (forward() is deprecated in v10 and a ForwardResponse should be used in v11) is however a breaking change to the extension, since the forward will not change the URL any more. In case the URL is used for tracking purposes, this will not work any more.

Since I'm not really convinced about the advantage of using a forward in this place, I will keep things as they are and continue to use a redirect (at least for the event registration).

[hannesbochmann]

Thanks for your response and I totally understand your decision but I'm seeing this a little different.

1. The extension could do something about it. Of course not every fault a user could make can be prevented. But the extension could be more robust in that special case. Instead of using forward() the registration could also be saved as confirmed when it's created instead of doing it later in another step after redirect. A redirect and everything else could still be done. It wouldn't change anything for the users just internally as the registration would be saved only once and therefore is either correct or none existent.
2. There can be a problem on the client side due to a slow internet connection and many other reasons that the webserver has no influence on. Again, it's not the fault of your extension and you can't deal with every possible problem. But the process could be more robust. In a perfect world this process would be done through a transaction so either it's completed and successful or it's rolled back like nothing ever happened. I guess for a simple event registration this might be a little over the top.
3. A forward would still make a little difference as it's still the same request. But I understand that the change to use a forward would have more downsides.

Of course you can always argue to fix the causes for errors or errors are outside of your control which you're absolutely right about. The registration is fine and works in most cases as intended but the process could be more robust. That's all I'm saying.