From ebe7c5ebb530251b603167fad0f78393c9c41d5f Mon Sep 17 00:00:00 2001 From: "ACE D. POL" Date: Sun, 30 Aug 2026 02:50:18 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20a=C3=B1adir=20secci=C3=B3n=20de=20bugs?= =?UTF-8?q?=20reales=20al=20README?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit expense-tracker-ui documenta el bug de ExpenseUpdate.date desde su lado, pero expense-api -- donde vive el bug y su fix con test de regresion (c3fb120) -- nunca tuvo una seccion equivalente. Mismo patron que personal-rag-assistant/-ui: cerrar la inconsistencia en el proyecto 1 del portfolio. --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index df8526b..0554bf3 100644 --- a/README.md +++ b/README.md @@ -103,3 +103,7 @@ Pendiente — requieren cuenta/credenciales externas propias, aplazados delibera - [ ] (Stretch) Endpoint que categorice un gasto automáticamente llamando a un LLM (necesita API key propia) Cada uno de estos pendientes debería vivir como un issue individual en GitHub, con su propia rama y PR, para que el historial del repo muestre trabajo incremental. + +## Bugs reales encontrados construyendo esto + +1. **`ExpenseUpdate.date` solo aceptaba `null`** — `PATCH /expenses/{id}` rechazaba con 422 cualquier intento de cambiar la fecha de un gasto. Causa: para una asignación anotada dentro del cuerpo de una clase (`date: Optional[date] = None`), Python guarda el valor de la derecha (`None`) bajo el nombre `date` en el namespace de la clase *antes* de evaluar la anotación `Optional[date]` — así que cuando la anotación se evalúa, `date` ya no apunta al tipo `datetime.date` importado, apunta a `None`. `Optional[None]` colapsa a `NoneType`, y por eso el schema de OpenAPI generado mostraba `"date": {"type": "null"}` en vez de una unión real de fecha/null. Solo ocurre porque `ExpenseUpdate.date` tiene un valor por defecto (`= None`) — `ExpenseCreate.date` y `ExpenseRead.date`, campos obligatorios sin default, nunca lo sufrieron, y esa asimetría es lo que lo hizo fácil de pasar por alto. Detectado desde el cliente tipado del frontend (`openapi-typescript` generaba `date?: null`, que no compilaba contra una fecha real) — ningún test existente lo capturó, porque `update_expense` solo estaba testeado con mocks que construyen `ExpenseUpdate` directamente en Python, sin pasar por la capa HTTP+Pydantic donde vivía el bug real. Arreglado importando el tipo bajo alias (`from datetime import date as date_`) y añadiendo `tests/integration/test_expenses.py` con este caso como regresión explícita.