vicidial_list status is NEW but called_since_last_reset is Y

[Louknows]

Hi,

I'm new to vicidial, and I was tasked to check on why there are numbers under CALLED in New status. See screenshot on this link:
https://ibb.co/1bXLRF1

As per checking on the database, these numbers are from:
vicidial_list table where called_since_last_reset = 'Y' and status = 'NEW'


My question is, what process in vicidial system that updates this column called_since_last_reset to Y keeping the status = NEW? If you can provide the page that do this or the PHP script being run, then that would be helpful. Any explanation to englighten the process would be helpful.

The reason I was tasked to check on this is because we have a lots of leads that are being thrown on that area (status NEW which is under CALLED - refer on the specified link above).

[carpenox]

perhaps they are duplicate records that have been called before, just under another list? that would be my best guess anyways.

[Louknows]

We have a job that change the list_id of 10k leads which status is NEW to another list_id by batch.. And another job that will change back the list_id to their original list_id when their status changed to something else like 'AA', 'NA', etc. Can it be the reason?

[mflorell]

The short explanation:

These are caused by Asterisk being overloaded for a short period of time.


The long explanation:

For leads that are called_since_last_reset=Y and status=NEW, sometimes when the load is high on an Asterisk server, it just won't run the dialplan entry of a phone call that is launched through the Manager, so the call is never actually dialed. This is very hard to track, but while I was working on Call Quota Lead Ranking two years ago I spent some time figuring out why it happens and how to mitigate it automatically. These no-dial calls happen in groups while the load is high on the Asterisk server, and Asterisk will show the Manager Originate command is accepted but it won't process it through the dialplan at all. As for mitigation, it is a rather DB-intensive set of queries that have to be run for each affected lead, so I only added this function as a part of the Call Quote Lead Ranking processes since it might add to the load issues on a heavy-dialing standard outbound auto-dial campaign.

[Louknows]

Thanks you for the explanation mflorell.

Since we want those leads to be dialable. Is it safe if we update the ff. columns in vicidial_list to:

Columns
user = null
called_since_last_reset = 'N'
last_local_call_time = null

Condition
where status = 'NEW' and called_since_last_reset = 'Y'

[mflorell]

You might want to check the called_count field as well.

[Louknows]

Should I update it also to zero?

[mflorell]

Sure. I would do a test on a single list first to confirm it does exactly what you want it to, and you shouldn't run it while you are actively dialing or it WILL cause issues.