- Navios
- 19 de agosto de 2026 às 06:49 UTC
- Autor
- Kamo
- Enviar
- 3729f10
Quatro falhas relatadas, uma causa. Um visitante widget não tem membro, então o membro do SYSTEM da org — o proprietário, que trabalha na fila — representa-os como solicitante do ticket e como autor de as suas mensagens. - O popup nunca ofereceu uma conversa de marketing. O predicado do bilhete de crédito recusa-se a oferecer qualquer um o seu próprio pedido; em um ticket widget que leia como o próprio proprietário. Um ticket no aplicativo tem um Um verdadeiro solicitante, e foi por isso que aqueles apareceram bem. - A lista de bate-papos não podia marcar um. getChatSessions contou "mensagens não escritas por mim", e as mensagens do visitante SÃO escritas sob esse membro — então, zero, sempre. Agora aplica-se o mesmo regra de autoria-ambiguidade getUnreadCountsPorMembro tem, e é por isso que a lista de tickets discordou. - A mensagem de um visitante chegou apenas ao membro do sistema, e sem os campos ACTIVIDADE as conversas filtros lista em, de modo que um agente que tinha entrado no chat não foi dito nada. - História nomeado o visitante após o membro suas mensagens são armazenadas sob, por isso ambas as metades do conversação lida como a mesma pessoa de apoio. A presença faz uma varredura de reconciliação. Apenas um fechamento observado foi anunciado; um socket que simplesmente parou (tab morto, laptop dormindo, rede se foi) envelhecido fora de Redis silenciosamente, então um visitante Quem saiu ficou verde até o agente recarregar enquanto um visitante que voltou ficou verde imediatamente. Um batimento cardíaco para uma chave que se foi agora reaviva-a, por isso a varredura não é uma porta de sentido único.