amount_paise has no upper bound, so a very large value crashes the request instead of being rejected.
Repro:
POST /expenses
{
"group_id": 1,
"title": "big",
"paid_by_user_id": 1,
"items": [{"name": "i", "amount_paise": 1000000000000000000000000000000, "participant_user_ids": [2]}]
}
Response: 500 Internal Server Error. The underlying error is OverflowError: Python int too large to convert to SQLite INTEGER, raised while inserting the row, and it is not caught anywhere (the service only wraps IntegrityError).
The frontend can trigger it too, since it just multiplies whatever is typed in the amount field by 100.
Suggested fix: validate in the schema, for example amount_paise: int = Field(gt=0, le=...) with a sensible cap, and possibly cap the number of items per expense. That would give a normal 422 for both create and update, and lets the invalid amount check in ExpenseService._compute_expense_totals stay as a second line of defence.
amount_paisehas no upper bound, so a very large value crashes the request instead of being rejected.Repro:
Response:
500 Internal Server Error. The underlying error isOverflowError: Python int too large to convert to SQLite INTEGER, raised while inserting the row, and it is not caught anywhere (the service only wrapsIntegrityError).The frontend can trigger it too, since it just multiplies whatever is typed in the amount field by 100.
Suggested fix: validate in the schema, for example
amount_paise: int = Field(gt=0, le=...)with a sensible cap, and possibly cap the number of items per expense. That would give a normal 422 for both create and update, and lets theinvalid amountcheck inExpenseService._compute_expense_totalsstay as a second line of defence.