-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GP-44423 Use background queues for SEPA batching #2
base: master
Are you sure you want to change the base?
Conversation
This fixes an issue where CRM_Sepa_Logic_NextCollectionDate may update next_sched_contribution_date for non-SEPA ContributionRecur entities when they are modified.
This temporarily disables all mandate repairs. Some of them cause data inconsistencies and performance issues on our environments.
Very interesting, @pfigel and @mflandorfer! I'm currently implementing the runner for the "mark received' process, and I guess it would make sense to implement this in the same way. Does this approach increase the minimum CiviCRM version? |
585e7e4
to
d728c1b
Compare
3725ebe
to
8abd3ff
Compare
07391ec
to
6cacbad
Compare
6cacbad
to
4c5846e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a test run with Queue_Close
with Sql
instead of SqlParallel
yesterday. I tried to close multiple groups at the same time (assuming that it would just queue them up and execute FIFO). It's hard to determine based on logs (due to the issue mentioned inline), but it looks like enqueuing a second close job somehow stopped one that was still being processed.
It's probably easiest to repeat the test after the flagged issues are fixed, as logs will be more useful then.
No description provided.