The recurring donations failure scan yielded several GC transactions that show as recurring in Civi, but do not show as recurring at the GC portal: transaction IDs are 4699088506, 630660817, and 6880374848.
There are also several possibly-related transactions that do appear as recurring donations at GC, but have not processed again yet, though this may be due to normal variability, as they are two days overdue: 3005420957, 2185631244, and 9264844762.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Blank submethod on method change, OID on recur change | mediawiki/extensions/DonationInterface | master | +108 -6 |
Investigating #4699088506 shows that the donor initiated a non-recurring donation via form email-cc-vma, then eight minutes later initiated a recurring donation via form rcc-vma. Both of these were in the same donation session and got the same order id. It looks like GlobalCollect allowed us to make two INSERT_ORDERWITHPAYMENT calls for the same order id and only counted the first (non-recurring) one. We treated the second (recurring) one as the real donation and recorded it as such.
The other two IDs mentioned had the same flow - initiate non-recurring, click continue to display iframe, don't complete, go back and initiate recurring, then complete.
I think we need to throw out order ID if the recur type changes.
Change 232525 had a related patch set uploaded (by Ejegg):
Blank submethod on method change, OID on recur change
Change 232525 merged by jenkins-bot:
Blank submethod on method change, OID on recur change
Thanks @Ejegg - will we know that this is solved just by not seeing more of them? If so, let's close this pending proof that it didn't fix :)