If a contact is imported to Acoustic, then the contact is deleted, then we get Mailing Data from Acoustic, this data is recorded on the deleted contact. In the case where the contact has been deleted via merge, ideally the data would instead be added to the contact that they have been merged into. The hazards of having slightly stale data in Acoustic!
There are currently about 6k contacts affected.
This was the cause of some of the strange observations in T395150.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Map IDs for merged contacts in omnirecipient load | wikimedia/fundraising/crm | master | +102 -1 |
So just updating contact_ids in the mailing data tables on merge isn't enough, because if we merge two contacts in Civi today in the AM, then before the next upload send mail via Acoustic to the deleted contact ID and pull in that info, it will reintroduce the deleted contact ID to the raw mailing data table. So in the process of moving data from the raw mailing table to the permanent one we'd want to to use getMergedTo, I guess.
Sorry, raw table vs permanent table only makes sense for the unsubscribes & opt-outs which have their own 'process' actions. The recipient load action looks like it's optimized for fast bulk inserts, so it might be tricky to remap deleted contacts on the fly without hurting performance. Perhaps before each batch insert, it could do a select for contacts where is_deleted=1 and contact_id in (cid_list), then remap just the ones that come back?
Hmm, I don't see that we are actually setting that insert_batch_size anywhere, so it's probably defaulting to 1.
Change #1230940 had a related patch set uploaded (by Ejegg; author: Ejegg):
[wikimedia/fundraising/crm@master] WIP map IDs for merged contacts in recipient load
Change #1230940 merged by jenkins-bot:
[wikimedia/fundraising/crm@master] Map IDs for merged contacts in omnirecipient load