Clasifica las traducciones fallidas sin perder la publicación

En una publicación multilingüe, "fallido" no es una sola condición.

La solicitud al modelo puede haber fallado. La traducción puede estar lista pero no poder enviarse a Contentful. La entrada localizada puede estar actualizada pero no publicada. Agrupar las tres bajo un solo estado rojo hace que el panel sea más simple y el trabajo de recuperación más difícil.

Comienza con la fase fallida

La traducción, el envío y la publicación son operaciones separadas con dependencias diferentes.

Un fallo de traducción puede deberse a un tiempo de espera del proveedor, una respuesta inválida del modelo o una validación de contenido protegido. Un fallo de envío puede implicar permisos, validación de campos o un conflicto de versión en Contentful. Un fallo de publicación puede reflejar el estado de la entrada, la configuración del entorno o el modo de publicación.

El primer filtro de clasificación debe responder: ¿qué fase necesita atención?

Eso reduce de inmediato la responsabilidad y los siguientes pasos.

Muestra el alcance del impacto

Una solicitud fallida necesita suficiente identidad para respaldar una decisión:

• nombre e ID de la entrada
• configuración regional de origen y destino
• lote
• fase fallida
• error más reciente
• cantidad de intentos y hora del último intento
• si las fases posteriores llegaron a comenzar

Sin ese contexto, los operadores abren cada solicitud individualmente y reconstruyen la publicación a mano.

La vista por lotes también debe distinguir el fallo parcial del fallo total. Si 49 de 50 configuraciones regionales tuvieron éxito, el equipo debería poder avanzar con el trabajo completado mientras recupera una solicitud.

Reintenta desde el límite correcto

Un reintento debe reanudar la fase fallida, no repetir cada fase exitosa anterior.

Si la traducción tuvo éxito y el envío falló, conserva la traducción revisada y reintenta el envío. Si Contentful se actualizó y la publicación falló, reintenta la publicación sobre el estado actual de la entrada.

Reiniciar desde la traducción puede generar un texto diferente, invalidar la revisión, aumentar el costo y ocultar el problema original.

Los reintentos conscientes de la fase mantienen estable el trabajo exitoso.

Separa los fallos transitorios de los permanentes

Algunos fallos son buenos candidatos para reintento automático:

• tiempos de espera del proveedor
• límites de tasa
• interrupciones breves de red
• conflictos de versión recuperables

Otros necesitan una persona:

• configuración de contenido inválida
• falta de habilitación de la configuración regional
• denegación de permisos
• estructura protegida que no puede restaurarse
• un campo de destino cambió después de la revisión

La política de reintento debe ser limitada y visible. Después de alcanzar el límite automático, la solicitud debe pasar a una cola humana con el último error útil intacto.

Mantén ligera la lista de fallos

Las pantallas de operaciones se usan cuando algo ya está saliendo mal. No deben activar una hidratación profunda del CMS para cada fila ni consultar con tanta agresividad que la página cree más carga que los workers que supervisa.

Devuelve primero los metadatos estables de la solicitud. Obtén el detalle completo de la entrada solo cuando un operador abra la solicitud.

El filtrado rápido es parte de la recuperación.

La conclusión

Una insignia roja no es un sistema de recuperación.

Separa los fallos por fase, muestra el alcance afectado y reintenta solo la operación que falló. Automatiza la recuperación transitoria dentro de límites claros y conserva errores accionables para todo lo demás. Los equipos pueden tolerar fallos individuales cuando el flujo de trabajo hace obvia la siguiente decisión.