Retroalimentación visual cuando un comando falla (dashboard) — 3 opciones — categoría solicitud-de-características-núcleo

¡Hola! :waving_hand:

Al trabajar en los parches de Netatmo (PR #2618), nos dimos cuenta de que un comando que falla (por ejemplo, una consigna de termostato cuando el servicio no está disponible) es invisible para el usuario: la API responde inmediatamente (arquitectura asíncrona de las acciones), el panel de control muestra el valor solicitado de manera optimista, y el fallo solo existe en los registros del servidor. El usuario cree que su consigna se ha aplicado cuando en realidad no se ha enviado nada.

La #2618 establece los prerrequisitos para Netatmo (el error ahora se propaga hasta el ejecutor de acciones en lugar de ser absorbido por el servicio), y nos gustaría proponer la siguiente etapa. Tres opciones, desde la más ligera hasta la más ambiciosa — @pierre-gilles, nos gustaría tu opinión sobre el concepto antes de escribir nada :slightly_smiling_face:

Opción A — Reconciliación de estado (recomendada)
En caso de fallo, el servidor emite un evento de WebSocket y el panel de control muestra el valor real (anulación de la actualización optimista) con un indicador discreto y temporal en el control afectado (:warning: «Comando no aplicado»). No se introduce un nuevo canal de notificación: solo una interfaz de usuario honesta, donde el usuario mira. Funciona de la misma manera en PC, móvil y tableta, ya que el indicador está en la tarjeta del dispositivo.

Opción B — Mensaje a través de la API existente (patrón de notificación de actualización 4.58)
Fallo → mensaje al usuario que inició el comando, a través de la API de mensajes: visible en Discusión, Telegram, notificación push de Gladys Plus. Con deduplicación para evitar el spam si un servicio no está disponible durante mucho tiempo.

Opción C — Toast genérico
Un pequeño componente de toast global (WebSocket ui.notification), alimentado inicialmente por los fallos de comando, reutilizable luego por otros dominios del núcleo. Es la opción más rica, pero también la que plantea más preguntas (persistencia, historial…).

Nuestra preferencia: A, posiblemente complementada con B — las dos siguen siendo pequeñas y no introducen un «sistema de notificaciones» que mantener. Por supuesto, C también es una opción viable como complemento en el futuro sin ser « obligatoria ». ¿Qué opinas?

¡Hola @Terdious!

Totalmente de acuerdo en que podría mejorarse, y la opción A me parece un buen camino.