Tu API devuelve 200 OK, pero los datos están mal 🤯

Imagina el escenario: el cliente reporta datos faltantes, revisas la base de datos y todo está ahí. Miras los logs y todas las peticiones responden con un 200 OK. No hay excepciones, no hay errores en Sentry. Solo datos incorrectos.

Este es el peligro de los "fallos silenciosos".

En ecosistemas como Supabase y PostgREST, existen comportamientos por defecto que actúan como contratos invisibles. Por ejemplo, una consulta .select() sin un .order() puede truncarse exactamente en 1000 filas sin avisar. El sistema no falla; simplemente te entrega un payload incompleto.

El problema real no es la herramienta, sino confiar en los "vendor defaults" que no están escritos en tu repositorio.

Para evitar que tu producción se convierta en un campo de minas, aplico estas 4 reglas de arquitectura:

• Materializa los defaults: Cualquier comportamiento implícito del proveedor debe convertirse en un ADR o una regla explícita en el proyecto. Si no está escrito, no existe.

• Automatiza la guardia con ESLint: El code review humano es inútil contra patrones repetitivos. Una regla de AST (Abstract Syntax Tree) detecta la falta de un .order() en mil archivos en un segundo.

• Implementa Sondas de Deriva (Drift Probes): Los unit tests no detectan problemas de volumen o contexto de auth. Necesitas monitoreo en producción que alerte cuando un contador toque un "techo" sospechoso.

• Docs > IA: No le preguntes a un LLM cómo funciona la versión actual de un proveedor. Lee la documentación oficial y materializa ese conocimiento en código o pruebas.

La vigilancia humana no escala. La única defensa real son las guardias materiales que impiden que una clase entera de incidentes vuelva a ocurrir.

¿Cómo están gestionando los comportamientos implícitos de sus proveedores de Cloud para evitar estos fallos silenciosos?