[SSF-146] handle recurring donations

[amywng]

ℹ️ Issue

Closes SSF-146

📝 Description

Implemented logic for processing recurring donations - every day, the cron job calls the service to check whether any scheduled donation dates have passed, send an email to the FM (placeholder log for now), and reschedule the next occurrence.
handleRecurringDonations():

• fetches all donations and filters for ones with past dates in nextDonationDates
• for each past date, log a placeholder for sending an automated email to the FM
• decrements occurrencesRemaining and removes the date from nextDonationDates
• calculates the next scheduled date using recurrence and recurrenceFreq (in a helper called calculateNextDate()) and adds it to nextDonationDates if there are remaining occurrences
• handles cascading recalculation - if the replacement date is also in the past, it continues advancing and decrementing occurrencesRemaining until a future date is reached or occurrences run out

Added service tests to cover all cases

• I added an insertDonation() helper to easily insert a new donation with custom recurrence info

✔️ Verification

Tests pass

[dburkhart07]

looks really good so far! this function looked like it was kinda evil to do 😅

[dburkhart07]

just a few small things for the tests ✈️ 🌵

[Yurika-Kan]

yayayya donations are being recurred. big things happening.

responded back to bigger comments & one test case!

thanks amy <3

[dburkhart07]

Few small nits. Can you also verify that the Cron job is also actually working with this? I tried setting it to @Cron('* * * * * *'), and it seemed to run, but I did not see any database updates happening.

[dburkhart07]

Why do we need this default? If this is just a helper, similar to the previous comment, i dont think recurrenceFreq will never null when calculateNextDate is called, since its only called when the recurrence is not NONE.

[amywng]

needed for strict mode. alternative would be to throw an error in generateNextDonationDates if donation.recurrenceFreq is null before calling this helper, but we already know it's not null based on the way the db is set up (and the check that the recurrence isn't NONE) so i think this is the best way to handle strict mode on this

[dburkhart07]

Do we need a conditional here? If nextDonationDates is not null and has a length of 1, then the first element of it exists. Think we can just do donation.nextDonationDates![0]

[amywng]

the linter complains when i try to do non-null assertion

[dburkhart07]

Can we make sure the month is also feb?

[amywng]

it technically is going to set it to whatever month is in the future from today, and pass all of the months from jan 31, 2024 to the current date (which is why i have the occurrencesRemaining set to 500 in case these tests matter like 40 years from now...) i've changed it to 1/31/2026 but it's not going to be deterministically february as the month. i think it's fine because this test is only validating the date clamping behavior and there are other tests that make sure the month is right

[dburkhart07]

lgtm!! 🌇 🌴

[Yurika-Kan]

Few small nits. Can you also verify that the Cron job is also actually working with this? I tried setting it to @Cron('* * * * * *'), and it seemed to run, but I did not see any database updates happening.

note here: my postgres had australia set as the time zone from reinstalling it during my dialogue, which affected the nextDonationDates array it generated - very small chance this would happen for client but good to flag this & might be nice to set explicit timezone in the cron job if it is a real concern

[Yurika-Kan]

LGTMMM so so awesome

tested cron via postman:

• single past due date
• multiple backlog past dates (cascade)
• null constraints
• cron daily + email logs

note: make sure to check postgres's time zone setting