Funraisin

Matched giving lets a sponsor match donations up to a cap, and strict handling is meant to stop matching once the cap is reached. It did not hold under concurrency. Two donations submitted at the same instant could both read the remaining match pool before either had written its own match, so both matched and the sponsor was charged past the cap.

I moved the calculation into the model used by donation pages, then added a per-pool MySQL named lock around the calculation and matched-donation insert. I applied the lock across seven donation paths and wrapped each use in try/finally so it releases when processing succeeds or throws.

Matched-giving requests for the same pool now pass through one locked calculation and insert path. I submitted two donations to the same pool at the same moment from separate browser sessions, then read the donation rows back to see that one match calculation had landed and the total had stayed under the sponsor's cap. This was a manual check, not a load test: it covers a genuine concurrent submission and says nothing about sustained volume.

I later rebuilt the pattern from scratch, without client code, at github.com/imrdwi/matched-giving-lock. The rebuild adds what the production change did not have: an automated test that fires real concurrent requests.

After the matched-giving fix, I checked the raffle sale path for the same race and found it there. Concurrent raffle requests could both try to create the sale linked to the same purchase. A fixed delay hid the race without controlling which request created the record.

I made creation atomic by claiming the temporary raffle sale record — deleting it and checking affected rows. The winner inserts the raffle sale. Losers see zero affected rows, wait 2 seconds, and look up the committed sale by order number instead of creating a duplicate.

I reproduced the race with a script that replayed a completed payment's PayPal webhook payload as 20 concurrent requests alongside the genuine one, so 21 hit the path at once. Before the fix, it left 21 sale records: 1 from the genuine request and 20 from the replay. After the fix, it left 1. This was a manual replay check, not an automated regression guarantee. The result alone does not establish what happens if the winning request stalls or fails after claiming the temporary record. There is no automated race test yet.

Advanced PURLs give each supporter a personal campaign link with pre-filled amounts, generated in bulk from a CSV import. An import failed on the first attempt and succeeded on retry. Reproducing it from the recording on the ticket, I found the failure in parsing the template the admin interface itself provides: quoted fields broke the parser, and an empty value shifted the remaining columns into the wrong fields.

I rewrote the parsing to handle quoted fields and empty values, then ran other CSV samples through it to confirm they still parsed and that the duplicate-email check still held. I had added that check earlier: before insert, each row's email is compared with the campaign's existing records and with rows already read from the file, so a supporter is imported once per campaign even when an import runs again.

I also made expiry and usage mode configurable settings, made expired PURLs load their page and form normally, and added search to the admin interface, which was unusable once an account held thousands of records.

The downloaded template imports on the first attempt, and running an import again does not duplicate supporters already in the campaign. I merged and deployed the fix and checked that the reported failure no longer occurred. Expired links open a normal page, and administrators can find a record without paging through the whole set.

Intelligent Giving suggests donation amounts. The logic is small, but it had to reach every donation form: platform-level and event-level settings rendering correctly across all four template generations. Releasing everywhere at once would have changed donation-form behavior on every platform simultaneously.

I implemented the settings across that matrix and put the feature behind a beta switch so it could be enabled per platform instead of globally. Most of the follow-up work was configuration failing on one specific path. Defaults did not update, a preview did not reflect a change, and dollar handles (the preset donation-amount buttons) did not resolve when an event relied on platform defaults.

Each platform could enable the feature independently. I verified that the disabled preview preserved its manually configured handles and that the enabled preview resolved Intelligent Giving defaults, and I fixed the reported fallback defects in the affected template paths.

A client syncing to Salesforce found donations staying attached to the wrong campaign after a fundraiser was moved to a new team. Nothing errored, and the platform's own screens were correct.

Moving a fundraiser's donations updated the team reference on those records but did not touch their last-updated timestamp. The Salesforce sync uses that timestamp to decide what has changed, so from its side nothing had. Finding it meant reasoning about how change detection worked, not reading a stack trace.

Updating the fundraiser's team now also updates the change signal consumed by the Salesforce synchronization path. The next sync can therefore pick up and reprocess the affected donations. I never watched a sync reprocess those donations. I confirmed that the timestamp gets updated, and the reprocessing follows from how the sync decides what has changed.