O día en que un parche menor dunha dependencia tirou o checkout dun cliente
Hai cousa de oito meses actualizamos unha libraría de pagamentos na tenda online dun cliente de moda infantil. Foi un npm update, nin sequera un salto de versión maior: de 4.2.1 a 4.2.3, dous parches. O changelog dicía “bug fixes and performance improvements”, esa frase que non di nada. Despregámolo un xoves pola tarde, sen pensalo moito, porque levabamos meses actualizando así sen problema.
Un parche menor dunha dependencia pode tirar a produción sen que o changelog o avise, sobre todo se toca timeouts ou formatos de resposta internos que a libraría non considera parte da súa “interface pública” — por iso agora tratamos as actualizacións de pagamentos, autenticación ou envío de datos con máis coidado que as dun compoñente visual. Iso foi xusto o que nos pasou: o venres ás dez da mañá o cliente escribiunos porque o botón de “Finalizar compra” quedaba cargando para sempre. Non en todos os pedidos, só nos que pagaban cun método de pago móbil concreto. Tardamos case tres horas en atopar que o parche cambiara en silencio o formato dun timeout interno, e con conexións lentas o SDK morría antes de recibir a confirmación. Nada no changelog o mencionaba. Nada nos tests o collía tampouco, porque os nosos tests de checkout usan unha pasarela simulada que responde en 40 milisegundos, non nos 4 segundos reais dun móbil con mala cobertura nun pobo calquera.
Desde entón cambiamos a política, aínda que me custou admitir que facía falta cambiala. Ben, máis que custar, tardei en aceptar que o problema non era mala sorte, era o proceso. Agora calquera libraría que toque pagamentos, autenticación ou envío de datos a terceiros actualízase a man, próbase nun dispositivo real con throttling de rede, e espera ao luns. As demais (utilidades, compoñentes de interface, cousas que se fallan vense a simple vista) seguen o proceso automático de sempre.
Non é unha postura moi popular entre quen defende que hai que estar sempre na última versión por seguridade. E en parte teñen razón: atrasar parches tamén ten un custo, sobre todo se o atraso é de meses e non de días. Pero levar catro anos mantendo webs de clientes convenceume de que “está no changelog” e “imos notalo” son cousas completamente distintas, e que o criterio para decidir que actualizar rápido e que non debería depender do que se rompe se falla, non do doado que sexa automatizalo.
O que aínda non temos resolto é que facer coas dependencias transitivas, esas que nin sequera aparecen no noso package.json e que trae outra libraría de segundo ou terceiro nivel. Aí Dependabot nin sequera abre PR a metade das veces, e o fallo chega sen avisar, igual que cando algo se rompe en produción e te decatas por unha alerta en vez de polo changelog.