- Spegnimento
- 10 agosto 2026 alle ore 17:57 UTC
- Autore
- Kamo
- Impegno
- 4007c5b
Routing un nuovo biglietto ha funzionato all'interno della transazione di creazione, quindi qualsiasi cosa ha colpito ha rotolato il biglietto indietro con esso e il membro che chiede aiuto ha ottenuto "Failed a creare il biglietto" con nulla salvato ovunque. Due cose l'hanno colpita, entrambi latenti fino a quando le richieste di chat hanno iniziato a raggiungere questo codice — rotonda-robin aveva effettivamente mai eseguito in produzione, quindi non aveva mai incontrato YugabyteDB: - getEligibleAgents ha spazzato ogni riga applicata-destra nel org e filtrato in Java: migliaia di righe unite a `members`, eseguire in ritardo in una scrittura transazione. YugabyteDB può solo riavviare trasparente una lettura che è la prima dichiarazione nella sua transazione, così questo sollevato "Riavviare letto richiesto" (SQLState 40001). Ora utilizza la ricerca destra filtrata indicizzata che SupportQueueService e SupportPendingCountService già utilizzano. - Un tracker rotondi appena creato è stato chiuso immediatamente PESSIMISTIC WRITE. L'entità è inversione, quindi è SELECT ... PER UPDATE contro una riga questa stessa transazione non impegnata aveva solo inserito; non restituisce nulla e Hibernate solleva StaleObjectStateException. Nulla può contendere una fila che non esiste ancora — l'unico vincolo su TOPIC ID è ciò che regola una gara di creazione. Tracciatori esistenti sono ancora bloccati. Strutturalmente, il routing ora avviene nella propria transazione dopo che il biglietto ha impegnati (SupportController chiama routeNewTicket, cadendo indietro a annunciareNewTicket se ciò fallisce). L'assegnazione è una convenienza; il biglietto è la cosa che deve sopravvivere. Questo dà anche l'assegnazione grande leggere un transazione dove è la prima dichiarazione.