Page MenuHomePhabricator

URGENT: Merge Behavior Changed — Causing RML Emails to Be Sent in Error!
Closed, ResolvedPublic

Description

Donor CID 39778356 and ticket #1710153 had their records merged on August 6.
The normal behavior of record merging will move the secondary email into the primary CID and mark it as opt-out in Acoustic, ensuring no further communications are sent to it, even though the secondary email can still be seen in Civi as such.
Even the merge screen explicitly states that one CID will be deleted after the merge. However, in this case, both emails remain active in Acoustic, which is highly concerning and suggests a possible issue in the merge process or the communication between Civi with Acoustic.

Timeline:
July 28: Contribution made
August 5: RML2 sent to primary email
August 6: Merge performed
August 12: RML3 sent to secondary email (which is not showing up in Civi), yet the donor replied to this email

There’s also this Slack thread suggesting a similar issue. Since this involved a two-email merge, we had assumed it was resolved—but clearly, that’s not the case.

The ability to search and save the secondary email shouldn’t have changed the merge results. Can a rule be added to opt out secondary email at Acoustic, should it be broken? This raises serious concerns about data integrity. Could someone please investigate this? Please feel free to add anyone else to the phab if needed. Thank you.

Event Timeline

Argh staging is down so I can't see the various calculated tables

greg triaged this task as Unbreak Now! priority.Aug 13 2025, 3:24 PM

Using this ticket as a mental notepad:

I did some digging and found that the secondary email exists twice in our DB, which might be a factor.

First record:

id: 68124209
created_date: 2025-07-25
source: Silverpop Added by WebForms
is_delete: 1
is_primary: 0
do_not_email: 0
do_not_phone: 0
do_not_mail: 0
do_not_sms: 0
is_opt_out: 0

Second record:

id: 39778356
created_date: 2019-12-14
source: online donation
do_not_email: 0
do_not_phone: 0
do_not_mail: 0
do_not_sms: 0
is_opt_out: 0
is_deleted: 0
is_primary: 0

I believe there are 35 affected contacts

SELECT c.id, MAX(c.modified_date) FROM silverpop_export_staging s LEFT JOIN civicrm.civicrm_email e ON s.id = e.id LEFT JOIN civicrm.civicrm_contact c ON c.id = e.contact_id GROUP BY e.email HAVING MIN(is_deleted) = 1;

+----------+----------------------+

idMAX(c.modified_date)
566826802025-08-13 04:25:03
661391502024-11-30 07:08:10
653210402024-10-19 18:16:02
78932392025-08-13 15:49:40
378240292025-08-13 05:02:28
583870342025-08-13 16:15:40
203606972025-08-13 15:53:09
674793552025-03-26 07:24:55
418006222025-08-13 04:29:12
664338632024-12-07 07:16:46
105408892025-08-13 03:55:51
655959352024-10-27 07:02:06
673585642025-01-23 00:28:09
655038822024-10-24 07:17:53
674739632025-03-25 12:32:49
661220652024-11-28 07:25:15
632282872024-12-17 14:47:34
427204722025-08-13 15:28:30
664953362024-12-08 10:08:27
664323372024-12-07 07:11:38
653324762024-10-11 07:04:57
643963382025-08-13 05:19:51
681242092025-07-25 07:28:20
675337922025-04-02 12:57:41
664342352024-12-07 07:17:17
664449302024-12-07 12:40:09
653970162024-10-16 17:09:40
660689362024-11-26 07:07:37
674788372025-03-26 07:24:04
444405882022-03-09 13:22:41
649873632025-01-16 08:44:05
605913972025-08-13 15:51:36
675426902025-04-03 07:34:27
663195552024-12-05 07:04:56
428397482025-08-13 08:47:28

35 rows in set (17 min 20.338 sec)

Actually it is less than 25 - the cluster modified date of 13-08-25 were ones that would have been removed overnight -

I ran a one off query

DELETE s FROM silverpop_export_staging s  INNER JOIN civicrm.civicrm_contact c ON contact_id = c.id WHERE c.is_deleted = 1 AND c.modified_date < DATE_SUB(now(), INTERVAL 10 DAY) ;

That picked up the contact & 59 other rows - I expect her to move onto the suppression list overnight - I can't see why she would not have been removed in late July as the script is trying to & as seems to work for most

Note this issue affected 2-3 dozen other contacts

@Eileenmcnaughton, I can confirm that the affected donor is now on the suppression list.

@SHust, this donor should no longer receive emails to their secondary email, as expected. Let us know if it comes up again!

greg lowered the priority of this task from Unbreak Now! to High.Aug 14 2025, 2:49 PM
greg subscribed.

(changing from UBN to High as this should be resolved, we just wait to actually close tasks until our sprint review)

@Eileenmcnaughton, will the affected donors' secondary email be opted out? I checked a few of the CIDs from the list you shared above, and they are still appearing as opted-in at Acoustic!

@Eileenmcnaughton, below are a few CIDs I spot checked, and the secondary email is still not opted out at Acoustic:
CIDs where the secondary email is still opted in at Acoustic: 66444930
CIDs where both emails remain opted in, even though the secondary email wasn’t saved during the merge (primary is visible on the CID summary page, and the secondary can be found at Acoustic opted in): 67478837, 66068936, 66434235, 64987363

Change #1180709 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Fix is_deleted failing to update on delete

https://gerrit.wikimedia.org/r/1180709

So one thing I noticed is that the last modified date was not updated on the first deleted contact I investigated - this seemed to possibly play into it & I figured out how to address that

https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/1180709

I dug into the first one of the new ones & I can see how the out-of-date modified_date could lead to that contact not being added to the suppression list

Thanks for the update, @Eileenmcnaughton. Please let me know if there's anything we need to do differently when merging to avoid issues!

XenoRyet set Final Story Points to 4.

Change #1180709 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Fix is_deleted failing to update on delete

https://gerrit.wikimedia.org/r/1180709

@Eileenmcnaughton and/or @jgleeson, today, CID 4420172 received email #2, even though they donated on 09/16. The message was sent to their 3rd email on file, which shouldn’t have happened.

That email address is active in Acoustic and is also listed as the primary email for an older CID (12922062) under a potential family member’s name, who last donated in 2015 and has not received communications from us.

Could you please look into why the merge process didn’t opt out all non-primary emails in Acoustic? We’re concerned this issue may be affecting others as well. Thank you!