Right @AMJohnson, we don't have any better information available to us on the form, so we're stuck trusting the codes we get back on the response.

OK @MBeat33 / @AMJohnson we figured out how to display the error within the Apple Pay sheet flow - it should now prompt them to add missing names right in their Apple Pay popup before submitting.

@Eileenmcnaughton was this for reminding people about grant deadlines?

looks like JQuery UI multiselect (used for the project & language targeting selectors) does not have a disabled state

As of early 2026 some elements are rendered read-only (dates, type, targeting checkboxes, banner assignment) and some elements are rendered editable (project & language targeting complex select boxes, country & region selectors, mixin-specific settings)

@spatton and @ATitkov that should be 1 by the time any in-banner code gets to read it.

I wonder if it would be best to do this in a contact save hook so we catch changes from the queue consumer and from the front-end.

Looks like @thiemowmde fixed it with the attached patch

fixed by 7a4c99b6675dd98d8151c09f8dab320c031b677f

fixed by 7a4c99b6675dd98d8151c09f8dab320c031b677f

There was an even worse bug! The new test caught the fact that we weren't even consulting the country field that we've been backfilling from the contribution tracking. I've added a new COALESE() clause to get that in there.

OK, the ungrouped 'INSERT / ON DUPLICATE KEY UPDATE no-op' seems to be a win - only 44 seconds for the select for the last two weeks on staging.

Trying the timing of the query for the last couple weeks on staging, I get this for the old query: "59 rows in set (51.617 sec)", and this for the new one: "59 rows in set (1 min 5.344 sec)"

We've added some documentation to the failmail zoo, and I changed the schedule to skip the check at 04:39 UTC which was giving a lot of false-positive failmails as it ran right when the job was usually legitimately still processing.

The following query suggests that a bunch of these actually DO have contribution tracking IDs, and the rest are manually entered (nulls in all the source_ fields)

Sounds good @AMJohnson, I'll move this ticket to 'Done' on our tracking board.

@AMJohnson My search results suggest that some issuers will show 'expired card' errors for the old card if the buyer has gotten a replacement card (i.e. due to losing the old one), even before the old card's expiration date. So maybe some of these folks have gotten replacements but still have the old card info saved in a browser?

@Lars I think you did this already, right? Shall we move it into a sprint and call it done?

Just merged it to wmf_deploy - it should go out this week!

OK, the fix to check dates is deployed, and the previously-reactivated ones have been set back to cancelled.

@Eileenmcnaughton the attached patch makes a couple fairly trivial methods on a deduper class static and public - if that's an issue I can just copy them to the save class

OK, those records are back in cancelled state. Just waiting for someone to review the code change to prevent it from happening again in the future.

I do see 50 or so records that have similarly short times between cancel and uncancel - I'll set them back to cancelled.

I see the cancel message come into our IPN listener at 11:06 AM that day, just a few minutes after a payment message on the same recurring. Since it was during Big English, the donation queues were pretty full and the cancel message got processed first. I can see in the db logs that the status went to cancelled, and then when the payment message came in we uncancelled it. I will update our uncancel logic to check the donation date.

Thanks for digging up that core issue! The example given on that ticket of 'employer of' with different dates is a good reason for having two, but I'd agree that a single active relationship per type with the same other contact makes sense.

Some examples:

SELECT contact_id_a, contact_id_b, relationship_type_id, COUNT(*) AS c
FROM civicrm_relationship
WHERE is_active = 1
GROUP BY contact_id_a, contact_id_b, relationship_type_id
HAVING c > 1;

I added an additional check to datachecks, but it looks like we're no longer actually running any of those in process-control. We do have some scheduled data integrity checks in the wmf-civicrm extension under WMFDataManagement though

Here's where to find (and delete) the local records: https://civicrm.wikimedia.org/civicrm/api4#/explorer/OmnimailJobProgress/get

Looks like the Datachecks extension would be a good place to add logic to find and fix these.

This issue was also reported as T392726: Lots of snooze activities on one contact. We put up one patch trying to fix it but it may not have been enough - looks like that patch was merged to deployment on Dec 23 and this contact has duplicate records up till Dec 30th.

Hmm, I don't see that we are actually setting that insert_batch_size anywhere, so it's probably defaulting to 1.

100 rows total failed out of more than one million sent

Well, once we migrate all the tokens over from the EC (and older) paypal-scheduled-recurring integrations, there won't be anything to record from SAR files anyway, so it's probably fine to move ahead without them.

I think we have been relying on these to create the initial donor and contribution_recur rows for recurring donations not recorded via IPNs or messages from the front end. Does the new PHP audit code handle creating those for new recurring donations just from the TRR files?

Just merged this to wmf_deploy so it should go out on next week's train

OK, I just merged the last one into wmf_deploy so it'll go out on next week's train.

There's a merge resolver rule to determine the 'better' casing between two name versions - let's see if we can use that in the update path of WMFContact\Save

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?

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.

Seems like a similar ticket was closed by @Jgreen in September: T405977: DNS resolution errors on payments1005 But this ticket shows the issues are ongoing. Removing chaos crew tag as this isn't something devs can fix.

Confirmed that it's working as intended - the only status that we can actually do anything about is pending-poke.

This seems to be due to a commit from last January https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/1115039