Una respuesta truncada puede parecer completa: cómo detectarla
Ver las primeras actas no prueba que el documento terminó bien. Totales, páginas, marcadores de cierre y estados por fuente ayudan a distinguir completo de cortado.
Por Marco Ferreiro ·
Una pantalla puede mostrar cinco actas ordenadas y parecer normal. Sin embargo, la descarga pudo cortarse antes de la sexta, el cursor pudo quedar sin seguir o una jurisdicción nunca alcanzó un estado terminal. Interpretar esas cinco como el universo completo convierte un problema técnico en una conclusión equivocada.
La integridad se verifica por capas: transporte, sintaxis, contrato, paginación y cobertura. Ninguna señal aislada alcanza para todos los casos.
Capa 1: terminó el mensaje
HTTP define cómo se delimita el contenido de una respuesta. Un cliente debe detectar cierres prematuros, diferencias con la longitud declarada o fallos durante la transferencia. Si el transporte informa error, no corresponde parsear los bytes parciales como resultado final.
Registrar status, encabezados relevantes, bytes recibidos y excepción ayuda a distinguir caída de red de una respuesta válida del servidor. Los cuerpos con datos sensibles no se copian a logs.
Capa 2: el formato es válido
JSON exige una estructura completa. Una llave o comilla sin cerrar hace fallar el parser, una señal clara. Pero la validez sintáctica es apenas el piso.
Un proxy podría entregar un objeto cerrado que contiene sólo la primera parte que tenía en memoria. También una aplicación puede serializar correctamente un estado parcial. Por eso el siguiente control necesita conocer el contrato.
Capa 3: están los campos de cierre
El esquema puede exigir status, completedAt, cantidad total o una lista de fuentes con estado. Si falta un campo requerido, el documento se rechaza aunque sea JSON válido.
Los opcionales no se convierten en ceros por comodidad. Ausente, null, lista vacía y cero representan cosas diferentes sólo si el contrato las define. Una normalización prematura puede borrar la pista del truncamiento.
Capa 4: cierran los conteos
Si la respuesta declara veinte elementos y contiene doce, hay una inconsistencia. Si declara doce pero además entrega un cursor, quizá sólo sea una página correcta. El validador debe entender juntos total, límite, página y cursor.
También se revisan subtotales por fuente. Un total global puede coincidir con lo recibido mientras una jurisdicción quedó fuera del cálculo. La lista de fuentes esperadas evita ese falso cierre.
Capa 5: se agotó la paginación
El cliente sigue next, cursor o número de página hasta una condición terminal documentada. Repetir el mismo cursor, saltar una página o recibir un cursor vacío en un estado no terminal son errores distintos.
Cada página se guarda sólo el tiempo necesario para componer la respuesta autorizada. Para auditar sin expedientes reales, usamos fixtures con IDs sintéticos y una secuencia conocida de páginas.
Capa 6: cada fuente terminó
Una consulta federal puede reunir varios organismos. Ver resultados de uno no prueba que los otros hayan respondido. Cada fuente esperada necesita estado: completa, vacía, error, pendiente o no consultable, según el contrato.
“Vacía” es un resultado terminal emitido por la fuente. “Pendiente” o “timeout” no lo son y nunca deben convertirse en cero infracciones.
Un laboratorio con cortes controlados
Partimos de un fixture completo y producimos variantes:
- corte en mitad de un byte multibyte;
- corte antes del cierre JSON;
- JSON válido sin campo terminal;
- total mayor que elementos;
- cursor omitido con páginas pendientes;
- fuente esperada sin estado;
- encabezado y cuerpo inconsistentes.
Cada caso tiene una única causa conocida y una aserción esperada. Así se comprueba que el detector no depende de un incidente irrepetible.
Qué mostrar sin perder lo recibido
Un resultado parcial puede ser útil si se etiqueta. La interfaz indica qué fuentes respondieron y cuáles faltan; la API conserva un estado explícito y permite reintentar de forma idempotente.
No se ocultan las actas válidas ya recibidas, pero tampoco se usa un título como “consulta completa”. El CTA y los procesos posteriores saben que falta cobertura.
Métricas que sí ayudan
Conviene medir respuestas rechazadas por capa, cursores repetidos, discrepancias de conteo y fuentes sin cierre. No se publican payloads ni identificadores para demostrar el problema.
Una subida repentina en “JSON inválido” apunta a transporte o serialización; una en “fuente pendiente” puede señalar otra dependencia. Separar categorías acorta el diagnóstico.
La regla operativa
Sólo un resultado que pasó todas las capas acordadas se marca completo. Todo lo demás conserva su estado real. Esa decisión puede parecer estricta, pero evita el error más costoso: presentar una respuesta prolija y cortada como si fuera un libre deuda.
Metodología
- Alcance
- Pruebas de integridad sobre respuestas HTTP, JSON y listados paginados mediante fixtures sintéticos completos y cortados.
- Unidad de análisis
- Respuesta esperada con bytes, campos terminales, conteos, cursores y fuentes, comparada con su variante truncada.
- Cobertura
- Cortes de transporte, JSON inválido, documento válido incompleto, página ausente y fuente sin estado terminal.
Limitaciones
- Las señales exactas dependen del contrato publicado por cada API o portal.
- El método detecta inconsistencias observables, pero no puede probar que una fuente omitió información que nunca declaró.
Fuentes
- HTTP Semantics specification — RFC Editor (consultada el )
- HTTP version 1.1 message syntax and routing — RFC Editor (consultada el )
- The JavaScript Object Notation Data Interchange Format — RFC Editor (consultada el )
- OpenAPI Specification version 3.1.2 — OpenAPI Initiative (consultada el )
Preguntas frecuentes
¿JSON válido significa respuesta completa?
No. Un documento puede cerrar sintácticamente y aun omitir páginas, fuentes o elementos respecto del total declarado.
¿Un HTTP 200 alcanza para marcar la consulta completa?
No. El código describe el resultado de esa respuesta; la aplicación debe validar contrato, paginación y estado de todas las fuentes esperadas.
¿Qué se muestra al usuario si falta el cierre?
Se informa resultado incompleto o fuente pendiente, preservando lo recibido sin presentarlo como ausencia total de infracciones.
Notas relacionadas
Captcha, login o acceso libre: qué cobertura habilita cada portal
Una barrera de acceso no significa falta de datos. Puede separar una consulta pública, información del titular y un trámite autenticado con alcances distintos.
Timeout no significa “sin multas”: cómo informar resultados parciales en una integración
Cuando una fuente no responde, el resultado es parcial o indeterminado, nunca cero. Un contrato explícito permite reintentar, alertar y decidir sin producir falsos negativos.
Cobertura declarada y cobertura efectiva: cómo medimos la diferencia
Un catálogo de fuentes promete alcance; una consulta demuestra resultado. Entre las dos medidas queda un hueco que registramos como estados con fecha, en lugar de disolverlo en un promedio.