Page MenuHomePhabricator

Recurring charge job not getting through that days charges in 24 hours (February 28 and future problem)
Open, Needs TriagePublic

Description

This is currently happening due to February only having 28 days , the recurrings set to charge on the 29,30, and 31 are being combined with the March 1 charges and not all finishing on March 1.

As of 2026-03-03 04:46 UTC it has gotten to recurrings started in November 2025.

I dug into this more yesterday, thanks @MBeat33 for bringing it up!

Currently recurring Adyen charges take 2 seconds per charge. The charge job runs twice an hour for 27 minutes each run, limited by time.

So with Adyen we are currently processing 810 charges per run, so 1620 an hour.
Gravy recurrings are at 540 per run, so 1080 an hour.

Using March 6 as an example:
Recurrings scheduled to charge March 6: 23631 (not including paypal as we don't manage those)
Adyen: 16416
Gravy: 6610
Dlocal: 226
Braintree: 379

Looking at Adyen and Gravy:
At 2 seconds per Adyen charge, it takes 10.13 runs or 10.5 hours to finish all the charges
At 3 seconds per Gravy charge, it takes 6.12 runs of 6.5 hours to finish all the charges

If all of the recurrings for March 6 had been moved to Gravy:
At 3 seconds per Gravy charge, it takes 21.3 runs so 21.5 hours

Event Timeline

Change #1249397 had a related patch set uploaded (by Ejegg; author: Ejegg):

[wikimedia/fundraising/crm@master] Run recurring charge jobs in parallel

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

Ejegg moved this task from Backlog to Ready for Review on the Fundraising Tech - Chaos Crew board.
Ejegg subscribed.

The attached patch will lets run an odds and an evens job in parallel. We could also write logic to run the adyen job in parallel to the gravy job, but if the idea is to move everything to gravy that wouldn't work in the long run.

Change #1249397 abandoned by Ejegg:

[wikimedia/fundraising/crm@master] Run recurring charge jobs in parallel

Reason:

Modulo is silly - easier to bucket by start_year or just min/max IDs

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

Fun way to get the middle ID to partition jobs by IDs

select median(id) over (partition by cancel_date)
from civicrm_contribution_recur
where contribution_status_id in (2, 5, 14, 15)
AND cancel_date IS NULL
and payment_token_id IS NOT NULL
limit 1;

Change #1267224 had a related patch set uploaded (by Ejegg; author: Ejegg):

[wikimedia/fundraising/crm@master] Add min/max recur_id params to segment charge jobs

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

Change #1267224 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Add min/max recur_id params to segment charge jobs

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

We have deployed the split job configuration, with one job running the older 1/2 of recurrings and the other job running the newer half.