fix(expenses): Correct data inconsistency for "Split Evenly" mode in context of default splitting#376
Open
Uli-Z wants to merge 1 commit intospliit-app:mainfrom
Open
Conversation
Contributor
Author
|
see also #375 |
Uli-Z
force-pushed
the
bugfix-incorrect-default-shares-evenly-mode
branch
from
f42b279 to
5551676
Compare
This commit addresses a data inconsistency issue where expenses with a split mode of 'EVENLY' could have non-normalized shares, leading to calculation errors in features like CSV exports.
This is a comprehensive fix that includes two parts:
1. **Application-level fix:**
The createExpense and updateExpense functions in src/lib/api.ts are updated to explicitly check if the split mode is 'EVENLY'. If it is, the shares for all participants are normalized to 1, ensuring that all new and updated expenses are stored with consistent data.
2. **Data migration:**
A new data migration is introduced to clean up existing inconsistent data. The migration updates the shares to 1 for all ExpensePaidFor entries associated with an Expense where splitMode is 'EVENLY'.
Together, these changes guarantee data integrity for all 'EVENLY' split expenses, both past and future.
Uli-Z
force-pushed
the
bugfix-incorrect-default-shares-evenly-mode
branch
from
5551676 to
abd3df6
Compare
Zufallsgenerat0r
pushed a commit
to Zufallsgenerat0r/spliit
that referenced
this pull request
Mar 11, 2026
…-app#376) Normalizes shares to 1 for all participants when split mode is EVENLY in both createExpense and updateExpense. Includes migration to fix existing inconsistent data. Cherry-picked from spliit-app#376 by Uli-Z.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.