21 Merged Pull Requests: Platform & Architecture
Talawa is an open-source community management platform maintained by the Palisadoes Foundation. It has a backend (talawa-api) and an admin panel (talawa-admin), both actively maintained, with real code review and a rule that new code needs solid test coverage before it can be merged.
Over a few months, I got 21 pull requests merged into these two projects. Here's what I built, the problems behind each one, and how I thought through them.
1. Finding Bugs Hiding in Untested Code
The backend stores its data using an ORM. Many table definitions and API functions had no tests at all. That's risky — a wrong rule in the code (like 'this field can be empty' when it shouldn't be) can break real data, and nobody notices until it's already a problem in production.
I wrote tests to catch exactly this. For each API function, I tested it the same way a real app would use it — send a request, check the response — instead of faking parts of it. For each database table, I checked five things every time: are the columns correct, are the relationships correct, are the indexes correct, do validation rules reject bad data, and do they accept valid data.
During an email-masking test PR, I found an unhandled edge case. Instead of silently 'fixing' behavior inside a test PR, I wrote a test documenting current behavior and opened a separate tracking note. Changing behavior and testing behavior are two different jobs, and mixing them makes both harder to review.
2. Fixing Tests That Failed for No Real Reason (Flaky Test Anatomy)
A 'flaky' test is one that sometimes fails even when the code is fine. Once a team gets used to tests failing randomly, they stop trusting CI test results, and real bugs slip through unnoticed.
I traced three separate flaky tests down to their actual root cause instead of just re-running them until they passed:
- 1. Mock Service Leak: A test faked a file-upload service improperly, leaking mock state into subsequent test suites.
- 2. Brittle Timers: Real timers (wait 5ms, wait 10ms) failed when CI runners experienced CPU throttling. Switched to deterministic fake timers.
- 3. Window Reload Side-Effect: A test called window.location.reload() in application code. Removing this unnecessary reload fixed the test and sped up user navigation.
3. Building a Security Feature: Rate Limiting
The 'request password reset' endpoint had no limit on how many times someone could call it. That's a real security gap — someone could spam a single email address with reset emails or hammer the server.
I built a limiter: 5 password reset requests per email address, per hour. Before doing expensive database checks or sending emails, it verifies the limit. Email addresses are normalized to lowercase before checking (A@x.com and a@x.com are treated identically).
Architectural trade-off: I chose an in-memory counter matching an existing pattern in the codebase (email verification limits) rather than adding a Redis dependency. Reusing established patterns keeps the codebase consistent and easy for the community to maintain.
4. Refactoring Code & Improving Documentation
Three separate refactors, same goal: remove duplicate logic so there's only one place to fix a bug:
- Notification deduplication: Merged ~45 lines of duplicate logic across notification dispatchers into a single shared helper.
- Modular setup validators: Extracted 7 buried validation routines into an independent module with backwards-compatible wrappers.
- Legacy chat format deprecation: Purged dual-format compatibility conditionals down to a single modern data pipeline.
- Production documentation: Overhauled the performance monitoring guide with real sample outputs and command telemetry.
In Short
Across these 21 PRs, the common thread wasn't the tools — it was the habit of asking 'what is actually causing this?' before writing code. Untested code got tests. Flaky tests got root-caused, not restarted. A missing security check got a proper fix, reusing what already worked. Duplicate code got merged into one place.
