Práctica focalizada · Bloque 4 · Unidad 4.3
EX-B4-07
Recuperar la sesión después de un conflicto unique
La base impide dos activos con el mismo tag, pero el endpoint intenta consultar con la misma Session justo después de IntegrityError y termina respondiendo 500.
Cómo abordarla
Haz que integridad y atomicidad sean observables
Ejecuta primero el baseline. Después modifica la frontera indicada, escribe una regresión positiva y otra negativa y conserva la salida real.
Evidencia objetivo: Los ensayos separan conflicto unique, presupuesto de carga y operación multirow; cada uno conserva evidencia del motor, no solo del body HTTP.
Abrir laboratorio de código
1. Descarga y arranca
- Starter con Session pendiente de rollbackAPI con UNIQUE real, cinco pruebas de continuidad y dos criterios visibles; el conflicto conocido deja la Session inutilizable.
2. Escribe y prueba
- Predice status, filas persistidas y resultado de una consulta posterior al conflicto.
- Ejecuta ambas suites e identifica la excepción de integridad y el error secundario de la Session.
- Haz rollback antes de reutilizar la Session y traduce solo el conflicto unique conocido a HTTP 409.
- Repite las pruebas e inspecciona la constraint y la fila conservada en SQLite.
3. Demuestra el comportamiento
- Corrección focalizada y pruebas finales.
- Secuencia observada de flush o commit, IntegrityError, rollback y consulta posterior.
- Explicación breve de por qué el pre-check puede mejorar el mensaje pero no garantizar unicidad.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
¿Qué estado conserva la transacción tras fallar el flush o commit y qué debe ocurrir antes de cualquier consulta posterior con esa Session?
Conflicto y recuperación
El segundo POST con tag repetido responde 409 y una petición posterior lista el primer activo usando una Session válida.Comprueba estas tres cosas
- ¿Qué impide realmente dos tags iguales bajo concurrencia?
- ¿Por qué consultar antes de insertar no reemplaza UNIQUE?
- ¿Qué demuestra que rollback recuperó la Session y no solo ocultó el error?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · El fallo cambia el estado
- Capturar IntegrityError no restablece por sí solo la transacción lógica de la Session.
- Haz rollback antes de consultar, añadir o confirmar de nuevo.
Pista 2 · Clasifica con precisión
- La constraint debe seguir en el DDL aunque exista una comprobación amigable.
- Traduce la violación que conoces; deja visibles los defectos inesperados.
Profundización opcional
Traducir una violación UNIQUE conocida a 409 y recuperar explícitamente la Session antes de volver a usarla, sin sustituir la garantía del motor por un pre-check.
Contexto adicional
- Ejecuta el baseline verde y después los dos criterios de aceptación sin editar.
- Conserva la UniqueConstraint y cambia solo la recuperación y traducción del conflicto conocido.
- No añadas un SELECT preventivo como garantía principal ni conviertas todo error de base en 409.
Decisiones abiertas
- Puedes aislar la traducción en una función pequeña o mantenerla en la operación; demuestra que la frontera transaccional sigue siendo visible.
Cómo revisar tu respuesta
- Los cinco tests de continuidad y los dos criterios transaccionales pasan.
- SQLite conserva una UNIQUE sobre tag y solo existe una fila para el valor repetido.
- El conflicto conocido responde 409 con un detalle estable; otros errores no se etiquetan automáticamente como duplicados.
- La Session recibe rollback antes de cualquier operación posterior y vuelve a ejecutar una consulta válida.
- No se usa un SELECT previo como sustituto de la constraint del motor.
Evidencia, revisión y reinicio
- Dos POST con el mismo tag y el estado observado de la Session después de IntegrityError.
- Cinco pruebas de continuidad verdes y dos criterios focalizados, uno inicialmente rojo.
- Constraint UNIQUE inspeccionada en SQLite y una consulta válida después del rollback.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-07-unique-rollback.zip y borrar solo el SQLite generado dentro de ese workspace.