fix: enforce transfer invariants when updating a transaction (#3)

The transfer rules — destination required, destination different from the
source account, no category, and no destination on a non-transfer — were
enforced by TransactionBase's validator on create, but the PATCH route only
re-checked category-vs-type.

So `PATCH /api/transactions/{id} {"type": "transfer"}` on an ordinary
expense committed a transfer row with transfer_account_id = NULL, and only
then failed serializing the response (TransactionRead inherits the same
validator). The caller got a 500 and would reasonably assume nothing was
saved — but from that point on every `GET /api/transactions` failed the same
validation, so the transactions list, the app's main screen, returned 500
permanently, with no way left in the UI to delete the offending row.

The rules now live in one place, transfer_rule_violation(), used by both the
create schema and the update route, so the two paths can't drift apart
again. The update path validates the row as it would look after the patch
rather than only the fields sent, since switching type alone invalidates
fields that were left untouched.

The frontend already sends a complete payload on edit (explicit nulls for
category_id / transfer_account_id) and does these same checks client-side,
so this only closes the hole for direct API calls — no UI change needed.


Claude-Session: https://claude.ai/code/session_01UmuMDFrwdvQkce885VaaTh

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

backend/app/api/routes/transactions.py

@@ -18,6 +18,7 @@ from app.schemas.transaction import (
     TransactionPage,
     TransactionRead,
     TransactionUpdate,
+    transfer_rule_violation,
 )
 
 router = APIRouter(prefix="/transactions", tags=["transactions"])
@@ -193,9 +194,22 @@ async def update_transaction(
     if transaction is None:
         raise HTTPException(status_code=404, detail="Transaction not found")
     updates = payload.model_dump(exclude_unset=True, exclude={"tag_ids"})
+    # Checks run against the row as it would look after the patch, not just
+    # the fields sent: switching type alone can invalidate fields left
+    # untouched.
     effective_type = updates.get("type", transaction.type)
     effective_category_id = updates.get("category_id", transaction.category_id)
+    effective_account_id = updates.get("account_id", transaction.account_id)
+    effective_transfer_account_id = updates.get("transfer_account_id", transaction.transfer_account_id)
     await _ensure_category_matches_type(session, effective_category_id, effective_type)
+    violation = transfer_rule_violation(
+        type=effective_type,
+        account_id=effective_account_id,
+        transfer_account_id=effective_transfer_account_id,
+        category_id=effective_category_id,
+    )
+    if violation:
+        raise HTTPException(status_code=400, detail=violation)
     for field, value in updates.items():
         setattr(transaction, field, value)
     if payload.tag_ids is not None:

backend/app/schemas/transaction.py

@@ -10,6 +10,35 @@ from app.schemas.category import CategoryRead
 from app.schemas.tag import TagRead
 
 
+def transfer_rule_violation(
+    *,
+    type: TransactionType,
+    account_id: int,
+    transfer_account_id: int | None,
+    category_id: int | None,
+) -> str | None:
+    """The transfer invariants in one place, returning the problem as text or
+    None if the combination is valid.
+
+    Both halves of the write path go through this: the create schema below
+    (as a pydantic validator) and the PATCH route (see
+    routes/transactions.py). Enforcing it on create only used to let an edit
+    produce a row that create would have rejected — most damagingly a
+    transfer with no transfer_account_id, which TransactionRead itself can't
+    serialize, so the row broke every later read of the transactions list.
+    """
+    if type == TransactionType.TRANSFER:
+        if not transfer_account_id:
+            return "transfer_account_id is required for transfer transactions"
+        if transfer_account_id == account_id:
+            return "transfer_account_id must differ from account_id"
+        if category_id:
+            return "category_id is not valid for transfer transactions"
+    elif transfer_account_id:
+        return "transfer_account_id is only valid for transfer transactions"
+    return None
+
+
 class TransactionBase(BaseModel):
     account_id: int
     category_id: int | None = None
@@ -30,14 +59,14 @@ class TransactionBase(BaseModel):
 
     @model_validator(mode="after")
     def _validate_type_specific_fields(self) -> "TransactionBase":
-        if self.type == TransactionType.TRANSFER and not self.transfer_account_id:
-            raise ValueError("transfer_account_id is required for transfer transactions")
-        if self.type == TransactionType.TRANSFER and self.transfer_account_id == self.account_id:
-            raise ValueError("transfer_account_id must differ from account_id")
-        if self.type != TransactionType.TRANSFER and self.transfer_account_id:
-            raise ValueError("transfer_account_id is only valid for transfer transactions")
-        if self.type == TransactionType.TRANSFER and self.category_id:
-            raise ValueError("category_id is not valid for transfer transactions")
+        violation = transfer_rule_violation(
+            type=self.type,
+            account_id=self.account_id,
+            transfer_account_id=self.transfer_account_id,
+            category_id=self.category_id,
+        )
+        if violation:
+            raise ValueError(violation)
         return self