spliit-app
fix(expenses): Correct data inconsistency for "Split Evenly" mode in context of default splitting
Summary This pull request addresses a critical data inconsistency bug that occurs when an expense is set to be split evenly, but a default (uneven) splitting configuration also exists. The bug caused incorrect amounts to be calculated in features like the CSV export because the underlying shares for participants were not being correctly normalized.
This PR introduces a fix in the core API logic to ensure data is stored correctly and adds a database migration to clean up any existing inconsistent data.
Problem Description When a user creates or updates an expense and selects the "Split Evenly" option, the application should divide the cost equally among all selected participants. However, if a default splitting configuration with uneven shares was previously set for those participants, the application was incorrectly preserving these old, uneven shares in the database while setting the splitMode to EVENLY.
This resulted in a contradictory state where an expense was marked as "evenly split" but had data indicating an uneven distribution. This incorrect data was then used in the CSV export, leading to confusing and inaccurate reports for users.
Solution Implemented The solution is two-fold to ensure correctness for both new and existing data:
-
API Logic Correction: The createExpense and updateExpense functions have been updated to enforce data consistency. Before creating or updating an expense, the code now checks if the splitMode is EVENLY. If it is, it programmatically overrides any incoming shares and sets them to 1 for all participants involved. This ensures that the data saved to the database is always correct from this point forward.
-
Data Migration for Existing Entries: A new Prisma migration has been added to clean up existing records in the database. The migration runs a single SQL UPDATE statement that finds all expenses with splitMode = 'EVENLY' and normalizes the shares in the corresponding ExpensePaidFor table to 1. This is a one-time fix that ensures historical data is also corrected.
