Surveda keeps retrying contacts when meeting the survey's end date

[matiasgarciaisaia]

When a contact's next hypothetical retry attempt is after the survey's end date, the SurveyBroker raises an error ("next active window not found") - and retries contacting the same respondent on the next poll.

Surveda correctly records the amount of retries it does, even if greater than the intended one - we've seen 96 attempts registered in the Respondents table in the UI.

The issue happens both on IVR and SMS modes.

We've 100% reproduced this setting a survey with a single active day, next to it's ending time. As a concrete example, on Thursday 03-OCT around 16:30 we've launched surveys that are active only on Thursdays from 16:00 to 18:00, with end date tomorrow (ie, 04-OCT).

When the SurveyBroker polls the survey, it sends the contact attempt to the proper channel, and then crashes with the mentioned error. The next time it polls the same survey, it sends the contact attempt once again, and again crashes.

10/3/2024 4:52:52 PM2024-10-03T19:52:52.572Z [info] Polling survey 4240 (active=0, pending=1, completed=0, batch_size=5000)
10/3/2024 4:52:52 PM2024-10-03T19:52:52.572Z [info] Survey 4240. Starting up to 5000 respondents (wanted to start 5000, batch limit at 100000).
10/3/2024 4:52:52 PM2024-10-03T19:52:52.649Z [warn] Adding again respondent (id: 13270392) to the histogram. Actual retry_stat_id: 2214555, previous: 2214554
10/3/2024 4:52:52 PM2024-10-03T19:52:52.653Z [error] Error occurred while polling survey (id: 4240): %Ask.ScheduleError{message: "next active window not found"} [{Ask.Schedule, :raise_date_exceeds_limit, 1, [file: 'lib/ask/ecto_types/schedule.ex', line: 346]}, {Ask.Schedule, :next_available_date, 4, [file: 'lib/ask/ecto_types/schedule.ex', line: 326]}, {Ask.Schedule, :reversible_next_available_date_time, 4, [file: 'lib/ask/ecto_types/schedule.ex', line: 250]}, {Ask.Runtime.Survey, :handle_session_step, 3, [file: 'lib/ask/runtime/survey.ex', line: 70]}, {Mutex, :apply_with_lock, 3, [file: 'lib/mut.ex', line: 262]}, {Enum, :"-each/2-lists^foreach/1-0-", 2, [file: 'lib/enum.ex', line: 783]}, {Enum, :each, 2, [file: 'lib/enum.ex', line: 783]}, {Ask.Runtime.SurveyBroker, :poll_survey, 3, [file: 'lib/ask/runtime/survey_broker.ex', line: 176]}]

[ ... ]

10/3/2024 4:53:52 PM2024-10-03T19:53:52.715Z [info] Polling survey 4240 (active=0, pending=1, completed=0, batch_size=5000)
10/3/2024 4:53:52 PM2024-10-03T19:53:52.716Z [info] Survey 4240. Starting up to 5000 respondents (wanted to start 5000, batch limit at 100000).
10/3/2024 4:53:52 PM2024-10-03T19:53:52.873Z [warn] Adding again respondent (id: 13270392) to the histogram. Actual retry_stat_id: 2214556, previous: 2214555
10/3/2024 4:53:52 PM2024-10-03T19:53:52.878Z [error] Error occurred while polling survey (id: 4240): %Ask.ScheduleError{message: "next active window not found"} [{Ask.Schedule, :raise_date_exceeds_limit, 1, [file: 'lib/ask/ecto_types/schedule.ex', line: 346]}, {Ask.Schedule, :next_available_date, 4, [file: 'lib/ask/ecto_types/schedule.ex', line: 326]}, {Ask.Schedule, :reversible_next_available_date_time, 4, [file: 'lib/ask/ecto_types/schedule.ex', line: 250]}, {Ask.Runtime.Survey, :handle_session_step, 3, [file: 'lib/ask/runtime/survey.ex', line: 70]}, {Mutex, :apply_with_lock, 3, [file: 'lib/mut.ex', line: 262]}, {Enum, :"-each/2-lists^foreach/1-0-", 2, [file: 'lib/enum.ex', line: 783]}, {Enum, :each, 2, [file: 'lib/enum.ex', line: 783]}, {Ask.Runtime.SurveyBroker, :poll_survey, 3, [file: 'lib/ask/runtime/survey_broker.ex', line: 176]}]

(Survey 4240 is IVR; we've seen the exact same error in SMS)

See #1862 for context.

[matiasgarciaisaia]

It's interesting to note that adding a single retry seems to avoid this issue.

I've tested an IVR survey with similar settings (single active day, active hours finish soon, survey ends tomorrow), but this time with a single 10m retry. This time, the survey worked as expected - survey started around 17:11, first call at 17:12 (didn't pick up), second call at 17:22 (didn't pick up), then the survey automatically finished. No errors logged either.

So having no retries seem to be a prerequisite.

I haven't tested mobile web, nor multimode.