Un catálogo puede mostrar el total correcto y aun así saltarse registros entre páginas. La revisión debe comparar los identificadores únicos recibidos por el cliente, no solo el contador de resultados. CREA UN CONJUNTO REPRODUCIBLE En un entorno de pruebas, crea 75 registros y asigna a varias decenas la misma fecha y el mismo precio. Exporta los ID esperados mediante otra consulta. Recorre todas las páginas de 25 elementos y compara los conjuntos. Este escenario propuesto descubre fallos que unas fechas aleatorias pueden ocultar. Cuenta duplicados y ausencias por separado: tener la misma cantidad no demuestra que sean los mismos registros. DEFINE UN ORDEN COMPLETO PostgreSQL no garantiza el orden deseado sin ORDER BY. Resuelve los empates con un criterio único, por ejemplo ORDER BY created_at DESC, id DESC. Usa la misma regla en la lista, la exportación y la página siguiente. Revisa por separado los órdenes por precio, nombre y popularidad; cada uno necesita una regla para valores iguales. La segunda clave forma parte del contrato de la API, no solo de la presentación. CONTEMPLA CAMBIOS DURANTE LA VISITA Un orden determinista no congela el catálogo. Los registros nuevos entre consultas pueden desplazar las posiciones OFFSET. Para una lista continua, considera un cursor con la pareja created_at e id que avance tras la última pareja recibida. Es una opción de diseño, no una solución universal. Una exportación que represente una instantánea necesita límites de consistencia y un mecanismo adicional. Un cursor por sí solo no garantiza esa instantánea. REVISA EL CONTRATO DEL CLIENTE El cursor debe corresponder a los filtros y al orden activos. Al cambiar de categoría, comienza otro recorrido. Distingue el final de la lista de un fallo del servidor: un resultado vacío y una consulta fallida necesitan estados diferentes. Limita el tamaño de página, valida las entradas y no incluyas secretos en cursores. Guarda un registro del orden, filtros, ID recibidos y cambios simultáneos. CRITERIO DE ACEPTACIÓN Sin cambios en los datos, cada ID esperado debe aparecer exactamente una vez. Repite añadiendo y eliminando filas y documenta el comportamiento admitido. Un aviso claro sobre cambios es preferible a perder elementos sin explicación. Catálogo de dominios: https://domainevery.com/es/domains Fuentes primarias: https://www.postgresql.org/docs/current/queries-limit.html https://www.postgresql.org/docs/current/queries-order.html https://www.postgresql.org/docs/current/transaction-iso.html
