holch wrote:

Experience of survey respondent is more import than a missing email for the LS user.

Agreed.

Sorry it's only an opinion …

Since such email can be an alert for a broken survey (bad submit email alert) : if user think is survey is saved : it MUST be saved. It's really more important .

Data is the most important

DenisChenu wrote:

holch wrote: if user think is survey is saved : it MUST be saved. It's really more important .

If the threadstarter described the situation correct, than LimeSurvey is hanging on to send an email to an mailserver, which is not available. The timeout (might be solved via a little NGINX tweak here) then prevents that the respondent can complete the survey.

You're saying: It is more important that LimeSurvey tries to send the email instead of letting the respondent completing the survey.

The Data that someone completed the survey is lost. A redirection is lost.

I more say : The development must take priority over features that are not correctable with a good server ...

With your opinion : if i make a broken plugin : broke redirection or show end page. LimeSurvey must disable this plugin.
But : if this plugin make a major action (for example : preparing an order) : maybe it better if we brake.

I'm OK with the general part : when a broken system happen : log it as error and show a clean error to user.
If we have time : add a checkbox on Global settings to send all error to a specific email etc …

But, if you look at bugs.limesurvey.org/my_view_page.php : you see a lot of other error that seems most important , no ?

DenisChenu wrote: But, if you look at bugs.limesurvey.org/my_view_page.php : you see a lot of other error that seems most important , no ?

What is an important bug or feature request? That can only be decided if you offer a value system and a mission statement, to align and allocate resources to fix bugs and implement features according to.

@Denis: I feel like you didn't understand our comment. A problem with sending email confirmation should not impact saving the survey data or should not cause the system to look stuck. These should be fairly separate processes. So even if the admin email is not sent because of any problem (which might occur), the data should be still be saved and the survey should finish.

I prefer not receiving the admin email but having results saved and visual feedback to the participants that their data has been stored over Limesurvey trying to send the email and fail and with it giving the respondents the impression that their data might not be stored.

That is all we tried to say. I find it hard to understand that anyone would disagree with this opinion. But then, as you said, it is just an opinion.

holch wrote: These should be fairly separate processes.

That would be nice, but will not happen soon. A phpscript alone cannot handle that. The simplest form implementing it, seems to save failed mails into the database and repeat the mailing via cron job. Perhaps PHP7-8 or Yii offer other ways (e.g message brokers) to keep tasks in a background, but currently a fine-tuning of timeout will have to do the trick.

The issue seems to be not the common, since email normally isn't blocked for a longer time and the email transport itself is very easy.

holch wrote: @Denis: I feel like you didn't understand our comment. A problem with sending email confirmation should not impact saving the survey data or should not cause the system to look stuck. These should be fairly separate processes. So even if the admin email is not sent because of any problem (which might occur), the data should be still be saved and the survey should finish.

I understand but : separate process of sending email and produce page need a complete rewrite of ALL email process

1st part : create a sendEmail class
2nd : move whole event and whole mail sending in this class (without broking API …)

And finally : create a asynchronous system … stackoverflow.com/questions/14236296/asy...function-call-in-php
Or «maybe» try to render the page before sending email, on ALL mais sending part … (and fix bug that appear …)

Here : have a good mail system fix the issue. Then i understand why it's not a priority …

Well, the problems coming with fixing this is a totally different topic.

I can totally understand that this would involve a lot of time and effort and there might be more important things to implement and fix (depending on everyones own point of view).

But that doesn't mean that there could be a better approach out there. It might just not be high on a priority list.