Un harness etiquetaba tres fallos distintos con el mismo código de error

Un harness de integración venía reportando tres fallos distintos bajo una sola etiqueta. Las listas de failure_reasons que devolvían sus tres fixtures coincidían en la línea de en medio: EXEC_ARGUMENTS_MISMATCH, incluso en el caso en que la comparación nunca llegó a ejecutarse. El commit dd1a654 arregla el reparto de nombres y toca tres ficheros de código, además de las pruebas.

Los escenarios eran estos: argumentos que el parser rechaza porque no se pueden leer; una llamada legible que no coincide con lo que estaba congelado; y un objeto que el propio canonicalizador rechaza, de modo que la comprobación se queda a medias. Los tres caían en el mismo catch, y ese catch bautizaba el problema como un desajuste de argumentos. La etiqueta no mentía sobre que había pasado algo, pero callaba cuál de las tres cosas. El diagnóstico lo dejó pm25coder en los comentarios de la pieza sobre comparación de esquemas: el nombre se lee como un veredicto sobre el modelo precisamente porque no lleva sujeto.

Separar el parseo de la comparación

La corrección parte el bloque en dos. El parseo tiene su propio catch y emite EXEC_ARGUMENTS_INVALID cuando lo que llega no se puede leer. Solo si hay algo que comparar se entra en la segunda etapa, que distingue entre EXEC_ARGUMENTS_MISMATCH (se comparó y difería) y EXEC_COMPARATOR_ERROR (la comparación reventó). Los mismos fixtures, sin tocar, mueven solo la línea central. Hay además un catch de sobra que sólo el autor necesitó encontrar grepeando por cada sitio donde se añadía el nombre viejo, en un módulo distinto.

Lo que no era un renombrado

Desde fuera del repositorio, el cambio tiene pinta de renombrado y no de rediseño, como apuntó pm25coder. Dentro había otra cosa. Los motivos de fallo pasan por listas blancas ordenadas antes de salir: lo que no está en la lista se descarta sin avisar. Registrar el nombre nuevo en el código y olvidarlo en la lista deja ese fallo invisible, mientras el resto de la ejecución sigue mostrando sus errores. Y hay dos listas, no una, en dos módulos distintos: 26 códigos en un sitio y 20 en otro, siendo los 20 un subconjunto estricto de los 26. No son copias. La más estrecha es la que lanza un TypeError ante un código desconocido; la otra se lo traga. La que lanza es la que está bien.

Unificar ambos registros queda para otro cambio. El autor lo justifica: meter una refactorización de esa lista en un commit que dice ocuparse de etiquetas vuelve las dos cosas más difíciles de revisar.

El detalle del commit es lo que se lleva el lector: un filtro que descarta códigos no reconocidos convierte un fallo en silencio, y eso es peor que el problema que este parche resuelve. Cualquiera que mantenga un catálogo de códigos de error propio puede ir a mirar si el suyo avisa o se calla.