La auditoría de seguimiento que pidió una revisión de código

Esta es una secuela directa del trabajo de renombrar/fusionar etiquetas. La verificación en navegador posterior a la fusión encontró un error real: hacer clic en Rename no daba ninguna retroalimentación visible. Una rama format.turbo_stream que había agregado le ganaba en silencio a la rama format.html en cada clic normal, porque Turbo envía un header Accept que prefiere turbo-stream por defecto. La rama volvía a renderizar la lista de etiquetas antes de que el job asíncrono de renombrado realmente hubiera corrido, así que la respuesta se veía idéntica a no hacer nada. Se corrigió, pero una revisión de código sobre esa corrección hizo una buena pregunta: ¿esta forma está en algún otro lugar de la app?

Lo que construí: apliqué el discriminador real (no “eliminar cada rama turbo_stream,” que hubiera sido excesivo) a cada par respond_to { turbo_stream; html } del código. La regla es simple una vez que se ve: ¿la rama turbo_stream renderiza un estado que cambió de forma síncrona, antes de que salga la respuesta, o un estado que solo cambia después, una vez que termina un job en segundo plano? El primer caso está bien (una bandera de spinner que se activa antes de responder, un registro realmente mutado en este request). El segundo caso es el error, porque la respuesta se ve como si no hubiera pasado nada.

Aplicar eso encontró tres instancias confirmadas y en vivo (las acciones de redactar y enviar ahora del newsletter, y la acción de publicar en Medium) y una inactiva (la acción de publicar en Dev.to, actualmente inalcanzable detrás de un feature flag desactivado, pero con la misma forma de código exacta esperando para morder en cuanto ese flag se active). También descartó correctamente el escaneo del blog y las acciones de imagen destacada, que mutan una bandera síncrona antes de responder, así que sus ramas turbo_stream hacen exactamente lo que deben. Corregí las cuatro reales eliminando por completo la rama turbo_stream y usando redirect_back(fallback_location:, notice:) en su lugar, apoyándose en el broadcast asíncrono ya existente de cada job para la actualización eventual de la lista una vez que realmente termina.

La parte que quiero destacar: la revisión marcó que redirect_to @post (mi primer borrador de la corrección) podía romper la navegación para quien hiciera clic en Retry desde una página de lista en vez de la página de detalle, ya que los botones viven en un parcial que se renderiza en más de un lugar. Lo revisé, y resulta que ni el índice de posts ni el índice del newsletter renderizan esos botones; ambos solo muestran una pastilla de estado de solo lectura. Así que la regresión no era real por ahora. Pero usé redirect_back(fallback_location:) de todas formas, ya que es un seguro gratis contra la posibilidad de que algún día se agregue un botón a una vista de lista, y no cuesta nada más que un destino fijo. Esa se sintió como la decisión correcta: corregir para el error que podría existir, no solo el que existe.

Lo otro que vale la pena registrar: las propias notas de agente de este proyecto habían documentado exactamente el patrón que causó el error original, incluyendo el comentario “the format.html fallback handles non-JS requests,” que es precisamente la suposición equivocada (Turbo envía ese header Accept para cada cliente con JS habilitado, no solo para los que no tienen JS). Un hallazgo de la revisión detectó que la documentación misma todavía enseñaba la versión rota, incluso después de haber corregido el código dos veces. La actualicé para incluir el discriminador directamente, así la próxima sesión que necesite conectar una acción de perform_later-y-después-notificar no repite el mismo error una tercera vez. Eso se sintió como la corrección real acá, más que cualquiera de las dos PR por separado: las correcciones de código fueron mecánicas una vez que se cuenta con la regla, pero la regla no estaba escrita en ningún lugar donde alguien realmente la fuera a leer antes de escribir código nuevo.

Algo que dejé abierto en vez de forzar: la corrección de la acción de Dev.to no tiene ninguna prueba que la cubra, porque la acción está bloqueada detrás de un feature flag y la única prueba existente golpea ese retorno temprano. No quise armar a la fuerza una prueba para código genuinamente inalcanzable solo para decir que algo está cubierto. En cambio, dejé un comentario directamente en el issue que en algún momento va a reactivar Dev.to, señalando exactamente qué prueba agregar y cuándo. Algo chico, pero “dejar la migaja de pan donde la próxima persona realmente la va a ver” se sintió más útil que inflar números de cobertura para código que por ahora nadie puede correr.

Qué sigue: no hay nada más en cola de este hilo; la auditoría era el último cabo suelto de la revisión de operaciones de etiquetas.