Um chat ao vivo é reivindicado através do popup, nunca alocado

FixMediaService
Navios
10 de agosto de 2026 às 18:22 UTC
Autor
Kamo
Enviar
3b734ec

Rotear pedidos de chat através de round-robin foi o modelo errado e quebrou o O que foi feito para consertar. Um ticket atribuído sai da fila de pedidos (SupportQueueService requer Agent IS NULL), então alocando um chat parou a oferta de aceitação-popup para qualquer um — o resultado observado foi cada chat preso a um membro com um apelido em branco que não estava lá, e nenhum popup para Qualquer um. O filtro de disponibilidade adicionado para proteger contra isso também não funciona, porque disponibilidade status não é presença: logout escreve AWAY e nada outro sempre o esclarece, assim que um membro que simplesmente nunca assina lê DISPONÍVEL indefinidamente. Este org tem uma dúzia de tais linhas, e redondo-robin andou em linha reta em um. atribuTicket agora descodifica qualquer PRE TICKET independentemente da estratégia do tópico. A chat ao vivo vai para a fila e as páginas popup todos os agentes disponíveis, que é o caminho que requer um navegador ao vivo na outra extremidade; a atribuição acontece quando alguém aceita. Os tickets enviados no mesmo tópico ainda estão alocados por round-robin, e converterPreTicket ainda roteia um bate-papo através da alocação uma vez que se torna um verdadeiro bilhete intitulado. Mantido dos dois commits anteriores: o YugabyteDB read- reinstart e correções de auto-bloqueio e roteamento em execução em sua própria transação pós-compromisso.

Todas as alterações

Como o que vês no transporte?

Cada uma dessas atualizações pousa automaticamente em seu espaço de trabalho. Comece grátis e veja crescer semana após semana.

Começar Livre Para SempreVer Preços