CiviCRM Community Forums (archive)

I have 2 clients had the same problem that after sending a CiviMail, not all recipients got recorded an activity.

1. CiviCRM upgraded from 1.9 to 3.1.3
    Sent to 7000 recipients and only about 800 of them got recorded an activity. (I got the 800 info from table civicrm_activity_target with the mailing activity id.)
2. CiviCRM upgraded from 2.2.7 to 3.1.3
    Sent to 5000 recipients and only about 400 of them got recorded an activity.

I found all the contacts with activity recorded correctly are the contacts with the latest contact id. Eg, for the second case, all contacts with id greater than 20795 are recorded and activity but the older contacts have no activity recorded. I did a test to send email to test group (about 5 recipients) with no problem. There was no problem before upgrade.

I tested on demo site(300 contacts) but couldn't see this problem.

Any clue for this problem?

Rui

I have 2 clients had the same problem that after sending a CiviMail, not all recipients got recorded an activity.

1. CiviCRM upgraded from 1.9 to 3.1.3
    Sent to 7000 recipients and only about 800 of them got recorded an activity. (I got the 800 info from table civicrm_activity_target with the mailing activity id.)
2. CiviCRM upgraded from 2.2.7 to 3.1.3
    Sent to 5000 recipients and only about 400 of them got recorded an activity.

Did actually all 7000/5000 mails got sent (from CiviMail’s report)? CiviMail sends in batches, maybe the mailing didn’t finish.

Otherwise, as Lobo says, it might be performance issue – if the activity recording is inefficient and the mailing script can’t reset the PHP script timeout, it might be that in the default 30 seconds only 800/400 activities managed to get recorded.

I checked the civicrm_activity_target table and only 266 contacts got recorded. I can confirm some recipients got emails but not recorded activity.
The activity was recorded for contacts starting from contact id 26222 till the greatest contact id.  I wonder why it randomly picked up a contact id and recorded activity from it instead of recording from the smallest contact id.

Hm, this seems like a bug, but we’ll need to replicate it before fixing.

Is there any configuration change I can try on codes or server to improve the performance?

As Lobo said – can you try replicating the problem (ideally – on a local machine) while redirecting the emails to /dev/null (via CIVICRM_MAIL_LOG in the config file) on a 3.1.3 install? It might point out whether it’s a performance problem or not.

Did a few local tests and found the problem finally.

There is a MAX_CONTACTS_TO_PROCESS (default 1000) in CRM_Mailing_BAO_Job which I think is to reduce the work load of the server. This process limit cause a number of calls to api/v2/Acitivity.php civicrm_activity_create function.

In civicrm_activity_create function, it calls CRM_Activity_BAO_Activity::create. This function deleted all the activity_target records of the activity before recording activity target, which introduce the problem that processing more than 1000 contacts will delete the previous  activity_target records of this activity.

For example, if there are 2120 recipients, it records 3 times to the activity_target table. First 1000, then deletes the first 1000 and records the second 1000, then delete the second 1000 and record the remaining 120 records. This explains why only the greatest contact ids got the records.

If I comment this line (413 in latest trunk) "self::deleteActivityTarget( $activityId );", it will work. Is this line necessary? 
I changed the MAX_CONTACTS_TO_PROCESS to 10000 for now.

I have filed an issue http://issues.civicrm.org/jira/browse/CRM-6035

Hi,

This is an old thread, but I am still seeing this bug on my site using 3.3.6.

The mailing report of successful deliveries shows 5828 contacts receiving the email. You can’t search in the Successful Deliveries report, but spot-checking suggests their Contact IDs are all lower than 428xx.
 
Only 230 contacts have the Bulk Email activity recorded to their records. Their Contact IDs are 428xx through 433xx.

Have there been any further updates on this fix since 3.1.4?

Thanks.