Page MenuHomePhabricator

Skipping refunds for contributions still in Donations Queue
Closed, ResolvedPublic

Description

The Trustly transaction with ID: eb91697d-e4be-402a-8749-2315358a290d failed because of a cancel_payment_method error but it's still marked as complete in the database.

The fundamental reason for this is because of the race condition between the Donations Queue Consumer and Refunds Queue Consumer. The refund queue consumer consumed the refund message before the DQC was able to create the contribution record in our database there by leading to the error: "Skipping failed trustly transaction, as contribution not found in Civi! {"log_id":"eb91697d-e4be-402a-8749-2315358a290d"}"

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
XenoRyet triaged this task as Medium priority.Dec 22 2025, 8:54 PM

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

It stops throwing the MISSING_PREDECESSOR exception which would otherwise make the message be requeued for a later attempt. @Damilare, how about we just revert that special-case from the RefundQueueConsumer?

@Ejegg that makes sense, I just looked at our implementation. Looks like we may be sending the refund queue message in some instances where it isn't necessary. We should probably only save to Civi on capture_pending and sending the chargeback only on capture_failed. I can test that out.

XenoRyet set Final Story Points to 2.