- Navios
- 25 de agosto de 2026 às 15:34 UTC
- Autor
- Kamo
- Enviar
- 480ea74
Alertmanager receptor webhook em /api/internal/alerts/chat, assim um KamoDesktop alerta atinge uma pessoa em vez de um painel. Esta é a perna BEST-EFFORT. E-mail é o garantido, enviado independentemente por Alertmanager, por isso, um tópico de chat irresolvível — membro renomeado, alias apagados, nova base de dados — degrada-se ao "email only" em vez de ao silêncio. Um notificador que pode falhar fechado e tomar a indicação com ele é pior do que nenhum notificador, porque continua a ser uma cobertura. Daí 200-com-um-resultado em vez de um não- 2xx O Alertmanager tentaria novamente para sempre contra um membro que não existe. É necessário um membro remetente distinto do destinatário: findOrCreateChatSession apenas corresponde a duas sessões participantes, de modo que um alerta auto- endereçado Uma nova sessão sempre que disparava e enterrava a lista de conversas. Esse caso é denunciado e saltou em vez disso. Auth aceita X-Internal-Auth ou Autorização: Portador com o mesmo segredo — um AlertmanagerConfig webhook só pode definir a Autorização, nunca um cabeçalho personalizado. Comparado o tempo constante e falhando fechado quando não configurado, deliberadamente não o flooser equals() usado pelos endpoints internos mais antigos deste serviço, onde o segredo em branco configurado corresponde a um cabeçalho em branco fornecido.