Mantén tu parser vivo cuando la API añade un campo

Un feed JSON no se queda congelado. Los campos se añaden, los tipos de mercado se multiplican, y una enumeración gana un miembro que nunca has visto. Si tu parser trata toda sorpresa como fatal, tu pipeline cae un martes tranquilo sin nada más malo. La regla de trabajo es más vieja que JSON: exige los campos que usas, tolera todo lo demás.

Las adiciones no son roturas

Una API que añade un campo a sus objetos de evento no ha roto nada. El array de eventos sigue ahí, el cursor sigue ahí, y cada campo que lees sigue significando lo que significaba. El fallo solo ocurre si tu código insiste en conocer cada clave por adelantado, por ejemplo al deserializar a un tipo de registro rígido que rechaza miembros desconocidos, o al afirmar un conjunto fijo de nombres de mercado.

El runbook de manejo de errores ya traza la línea para la otra dirección: exige el sobre documentado, el array de eventos y el cursor, antes de tocar el payload. Esa exigencia trata de lo que debe estar presente. La compatibilidad futura trata de lo que también puede estarlo.

Dos reglas para un parser tolerante

Primero, lee por nombre, nunca por posición ni por listado exhaustivo. Busca los campos que tu lógica necesita e ignora el resto; un parser que itera sobre todas las claves y hace switch en cada una encontrará una clave para la que no tiene caso.

Segundo, valida valores, no vocabularios. Comprueba que el precio es un número mayor que uno, que la marca de tiempo parsea, que el id del evento está presente. No compruebes que el nombre del mercado pertenece a una lista que escribiste en marzo, porque la lista es la parte que envejece. La advertencia del runbook sobre los nulos también aplica aquí: un precio null significa que el mercado está cerrado o no disponible, y la respuesta correcta es mantenerlo null, nunca sustituirlo por cero.

Registra la deriva sin fallar por ella

Tolerancia no significa ceguera. Cuando tu parser encuentra un campo o un valor que no conoce, cuéntalo y sigue adelante. Una línea en nivel debug o un contador por clave desconocida basta. Una vez por semana, lee los recuentos: te cuentan lo que el feed añadió, que a menudo es una función que ahora puedes usar, como un nuevo tipo de mercado que puedes empezar a almacenar.

Esta es la diferencia entre derivar y romperse. Derivar es el feed creciendo a tu alrededor; romperse es tu código negándose a crecer con él.

Fija el contrato con fixtures

Un puñado de respuestas grabadas en tu suite de pruebas convierte la política en una comprobación: el parser debe aceptar los sobres grabados, extraer lo que usas, y encogerse de hombros ante un evento sintético con campos extra inventados. Cuando el feed documente un cambio genuinamente rompedor, eso es una migración a planear, no una sorpresa a sobrevivir. Hasta entonces, la tolerancia es el plan.

Exige el sobre, lee por nombre, registra lo desconocido. Un parser construido así solo se rompe cuando el mundo cambia de verdad, no cada vez que el feed aprende una palabra nueva.