You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If contacts are queued in the channel-broker but expire before they can be sent to verboice (or nuntium after #2283), the channel-broker will merely discard the contacts, and won't report the expired state back to the respondent session.
How will the session consider the respondent? Does the session assume that we tried to contact the respondent, and failed, and consumes a retry when it shouldn't? Or correctly assume that we didn't get any response, and won't consume a retry... ⏰
That won't crash or hang surveda. The batch size / limit per minute can be tuned to avoid too many excess contacts. The logs regularly report the number of active & queued contacts for each channel-broker, which may help to tweak the batch size / limit values.
If it's an issue, it might be fixed by the channel-broker making an internal call to report the contact as expired. That should be doable.
The text was updated successfully, but these errors were encountered:
Here is a screenshot of local survey where roughly 1600 IVR contacts expired yesterday evening (the simulator is confirmed to always reply). It seems that Surveda reported them as failed, which might hint that it will consume a retry to call them again?
If contacts are queued in the channel-broker but expire before they can be sent to verboice (or nuntium after #2283), the channel-broker will merely discard the contacts, and won't report the
expired
state back to the respondent session.How will the session consider the respondent? Does the session assume that we tried to contact the respondent, and failed, and consumes a retry when it shouldn't? Or correctly assume that we didn't get any response, and won't consume a retry... ⏰
That won't crash or hang surveda. The batch size / limit per minute can be tuned to avoid too many excess contacts. The logs regularly report the number of active & queued contacts for each channel-broker, which may help to tweak the batch size / limit values.
If it's an issue, it might be fixed by the channel-broker making an internal call to report the contact as expired. That should be doable.
The text was updated successfully, but these errors were encountered: