🔄 Update y rollback en producción: caso real con OpenClaw

En producción no actualizo software crítico con fe. Actualizo con rollback.

Este es el reporte técnico de un update real de OpenClaw, el motor que uso para operar Nova, mi asistente personal de IA. En menos de 24 horas ejecuté dos intentos sobre el mismo sistema:

• el primero terminó en fallo de plugins y rollback;
• el segundo terminó en update exitoso después de un fix upstream;
• en medio apareció otro bug que no estaba buscando: una sesión de Slack quedó pinneada a Gemini por estado persistido.

No es una guía genérica de buenas prácticas. Es el registro de lo que hice, lo que vi en logs, cómo decidí y qué quedó como checklist para la próxima ventana de mantenimiento.

Resumen operativo

Campo	Valor
Sistema	OpenClaw en producción
Uso principal	Motor de Nova
Canales críticos	Slack y WhatsApp
Versión estable inicial	2026.4.15
Primer target	2026.4.22
Resultado del primer intento	Fallo en plugins y rollback
Segundo target	2026.4.23
Resultado del segundo intento	Update exitoso
Tiempo de recuperación	Aproximadamente 15 minutos
Hallazgo adicional	Session pinning en Slack hacia Gemini

El punto importante: el protocolo no hizo que todo saliera bien. Hizo algo más útil: permitió decidir rápido, volver a estado estable y repetir el update cuando el fix correcto ya estaba disponible.

Protocolo base para update y rollback

Mi regla es simple: no instalo nada en producción si no sé cómo volver atrás.

El protocolo tiene seis pasos, siempre en este orden:

1. Documentar la versión actual.
   Esa versión es el punto de retorno. Si no sabes volver a una versión exacta, no tienes rollback; tienes intención de rollback.

2. Hacer backup de configuración y estado.
   Antes de tocar el sistema. No después del fallo. No a mitad del incidente. Antes.

3. Revisar documentación oficial.
   Changelog, issues abiertos, breaking changes y PRs relacionados. No para leer por deporte, sino para saber qué tipo de riesgo estás aceptando.

4. Instalar la nueva versión.

5. Verificar funcionalmente.
   No basta con que el proceso arranque. No basta con que doctor salga verde. Hay que probar los flujos reales: Slack, WhatsApp, jobs, cron, API, colas o lo que aplique en cada sistema.

6. Si hay una anomalía seria, rollback inmediato.
   No convertir producción en laboratorio. Primero vuelves al estado conocido bueno. Luego diagnosticas.

Un servicio que loguea ready puede estar roto. Por eso el health check no reemplaza la prueba funcional.

Intento 1: update de OpenClaw 2026.4.15 a 2026.4.22

El punto de partida era OpenClaw 2026.4.15, una versión que llevaba semanas estable. El target era 2026.4.22.

Antes del update revisé el release log oficial y los issues recientes. Vi señales relacionadas con plugins, pero no había una confirmación clara de que mi instalación fuera a romper. Como el rollback estaba definido y el backup estaba hecho, avancé.

Comandos base del procedimiento:

npm view openclaw@latest version
npm install -g openclaw@latest
openclaw doctor
systemctl restart openclaw
journalctl -u openclaw -n 100 --no-pager

Después de instalar, openclaw doctor reportó verde. Eso era una señal útil, pero no suficiente.

La verificación funcional contó otra historia. Slack y WhatsApp empezaron a fallar:

[whatsapp] channel startup failed: Cannot find package 'openclaw'
[slack] [default] channel exited: Cannot find package 'openclaw'
[slack] [default] auto-restart attempt 1/10 in 5s

El servicio principal no era el problema. El problema estaba en el runtime de los plugins. Los plugins corrían en un directorio aislado y desde ahí no podían resolver el paquete host openclaw.

Volví a los issues y encontré tres reportes con el mismo síntoma: #69837, #69842 y #67038. En ese momento no había fix oficial.

Criterio de decisión: por qué hice rollback

En ese punto tenía dos opciones:

1. Forzar un workaround manual.
2. Ejecutar rollback.

Probé lo justo para confirmar que el workaround podía hacer que algunas piezas respondieran, pero el estado quedaba mal: dependencias instaladas a mano dentro del directorio global del paquete, rutas no garantizadas y una alta probabilidad de romper otra vez en el próximo update.

Ese no era un estado aceptable para producción.

Matriz de decisión:

Señal	Lectura operativa	Acción
doctor verde	El binario principal responde	No suficiente
Slack falla	Canal crítico afectado	Bloqueante
WhatsApp falla	Segundo canal crítico afectado	Bloqueante
Issues upstream abiertos	Bug conocido sin fix publicado	No parchear a ciegas
Workaround manual frágil	Deuda técnica inmediata	Rechazar
Versión anterior estable	Punto de retorno válido	Rollback

Rollback ejecutado:

npm install -g openclaw@2026.4.15
systemctl restart openclaw
openclaw doctor
journalctl -u openclaw -n 100 --no-pager

Después vino la prueba que realmente cuenta: mensajes desde Slack y WhatsApp.

Resultado: producción restaurada en unos 15 minutos. Sin pérdida de datos. Sin estado corrupto. Sin dejar un parche escondido que explotara en el próximo mantenimiento.

Rollback no fue fracaso. Fue control operativo.

Hallazgo adicional: la verificación encontró otro bug

Después de volver a 2026.4.15, seguí probando cada canal. Ahí apareció un problema que no pertenecía al update: una sesión de Slack respondía con tres minutos de retraso. WhatsApp, con la misma configuración general, respondía al instante.

En el log apareció esta pista:

[agent/embedded] embedded run failover decision:
    reason=timeout
    from=google/gemini-3.1-flash-lite-preview

El agente estaba iniciando la conversación con Gemini, no con Claude Haiku, que era el modelo primario configurado.

La causa estaba en sessions.json:

"agent:main:main": {
  "provider": "google",
  "model": "gemini-3.1-flash-lite-preview"
}

La sesión de Slack tenía Gemini fijado como estado persistido. En algún momento anterior, un failover automático guardó ese override. Luego el sistema no volvió al modelo primario aunque Haiku ya estuviera sano.

Ese comportamiento estaba relacionado con el issue #22443 y con la forma en que OpenClaw maneja el Model Failover.

El fix fue reversible:

1. Mover el transcript activo fuera de la ruta usada por esa sesión.
2. Eliminar la entrada persistida del índice.
3. Reiniciar/verificar el canal.
4. Probar respuesta desde Slack.

Resultado: el siguiente mensaje respondió en siete segundos.

Este segundo bug no tenía relación directa con el update. Y precisamente por eso importa. Si la verificación se hubiera quedado en “el servicio está arriba”, ese problema habría seguido oculto.

Intento 2: update de OpenClaw 2026.4.15 a 2026.4.23

Al día siguiente salió OpenClaw 2026.4.23. Esta vez el changelog tenía el cambio que necesitaba: el instalador de plugins enlazaba el paquete host de OpenClaw para que los plugins con openclaw como peer dependency pudieran resolver sus imports sin duplicar el paquete.

El PR #70462 apuntaba exactamente al bug que había bloqueado el intento anterior. También confirmé que los issues #69837, #69842 y #67038 quedaban cubiertos por ese cambio.

No cambié el método. Repetí el protocolo.

Versión disponible:

npm view openclaw@latest version

Resultado:

2026.4.23

Punto de rollback documentado:

2026.4.15 (041266a)

Backup completo:

/home/openclaw/.openclaw-backup-20260425-0527

Instalación:

npm install -g openclaw@latest

Corrección/verificación de instalación:

openclaw doctor --fix

Reinicio:

systemctl restart openclaw

Validación en logs:

gateway ready
Slack socket mode connected
Listening for personal WhatsApp inbound messages

Validación negativa:

0 errores: Cannot find package 'openclaw'

Prueba funcional:

Canal	Resultado
Slack	Respuesta inmediata
WhatsApp	Respuesta inmediata
Modelo reportado	Haiku
Versión reportada	2026.4.23

Otros 15 minutos de trabajo. Esta vez no fueron para abortar el update, sino para cerrarlo bien.

Checklist reutilizable para updates en producción

Este checklist queda como base para próximos mantenimientos:

[ ] Versión actual documentada
[ ] Comando de rollback definido
[ ] Backup de configuración y estado realizado
[ ] Changelog revisado
[ ] Issues recientes revisados
[ ] Breaking changes revisados
[ ] PRs relacionados revisados si aplica
[ ] Ventana de mantenimiento definida
[ ] Update instalado
[ ] Health check ejecutado
[ ] Restart validado
[ ] Logs revisados después del restart
[ ] Verificación funcional por canal o flujo real
[ ] Validación negativa de errores conocidos
[ ] Comparación contra issues upstream
[ ] Decisión tomada: seguir, corregir o rollback
[ ] Resultado documentado

La línea más importante es esta:

[ ] Verificación funcional por canal o flujo real

Ahí fue donde apareció el fallo de plugins. Ahí fue donde apareció el session pinning. Ahí fue donde se confirmó que 2026.4.23 sí resolvía el problema.

Lo que quedó probado

El mismo protocolo produjo dos resultados distintos:

• con 2026.4.22, detectó un bug bloqueante y me llevó a rollback;
• con 2026.4.23, confirmó el fix upstream y permitió completar el update;
• en medio, destapó un bug viejo de session pinning que afectaba Slack.

Eso es lo que debe hacer un protocolo de update y rollback en producción.

No se trata de que todos los updates salgan bien. Se trata de que cada update tenga:

• punto de retorno;
• backup;
• evidencia;
• prueba funcional;
• criterio de decisión;
• salida limpia.

El protocolo no elimina los bugs de terceros. Tampoco convierte un release malo en bueno. Lo que hace es reducir incertidumbre y acortar el tiempo entre detectar un problema y tomar una decisión correcta.

Sin rollback, un update fallido se convierte en incidente.
Con rollback, un update fallido se convierte en un trámite controlado.

Esa es la diferencia entre operar producción y esperar que producción se porte bien.

---

Por: Cesar Rosa Polanco - Escrito a partir de una experiencia real, con asistencia de inteligencia artificial como herramienta de apoyo editorial