- Navios
- 10 de agosto de 2026 às 17:57 UTC
- Autor
- Kamo
- Enviar
- 4007c5b
O roteamento de um novo ticket foi executado dentro da transação de criação, então qualquer coisa foi atingida rolou o bilhete de volta com ele e o membro pedindo ajuda ficou "Falhou criar ticket" sem nada salvo em qualquer lugar. Duas coisas atingiram-no, ambas latentes. até que as solicitações de chat começaram a chegar a este código — round-robin tinha efetivamente Nunca foi executado em produção, por isso nunca conheceu YugabyteDB: - getEligibleAgents varreu cada linha de direitos aplicados no org e filtrado em Java: milhares de linhas unidas a `members', correr tarde em uma escrita transacção. O YugabyteDB só pode reiniciar de forma transparente uma leitura que é primeira instrução em sua transação, então esta levantada "Reiniciar leitura necessária" (SQLState 40001). Agora usa a pesquisa indexada filtrada à direita que SuporteQueueService e suportePendingCountService já usam. - Um rastreador round-robin recém-criado foi imediatamente bloqueado ESCRITO PESSIMÍSTICO. A entidade está sem versão, então isso é SELECT ... PARA ATUALIZAR contra uma linha esta mesma transação não comprometida tinha apenas inserido; ele retorna nada e Hibernate levanta StaleObjectStateException. Nada pode lutar por uma fileira que ainda não existe — a única restrição em TOPIC ID é o que resolve uma corrida de criação. Rastreadores existentes Ainda estão trancadas. Estruturalmente, roteamento agora acontece em sua própria transação após o ticket committed (SupportController chama rotaNewTicket, caindo para anuncieNewTicket se isso falhar). A atribuição é uma conveniência; o bilhete é A coisa que deve sobreviver. Isso também dá a grande leitura da atribuição transação onde é a primeira declaração.