- Shipped
- August 10, 2026 at 11:11 PM UTC
- Author
- Kamo
- Commit
- b3a3acc
A chat opened in the web widget is the same unit of work as one filed inside the app, but this path skipped the topic's assignment strategy entirely — the only assignment it ever attempted was the borrower's own loan officer. So one topic behaved two ways depending on where the visitor started: an in-app chat was auto-assigned, while a widget chat on the same topic sat on the queue waiting for somebody to accept it. Assignment runs after the session transaction commits, for two reasons. It reads the org's whole eligible-agent set, and a read that wide arriving late in a write transaction is exactly what YugabyteDB cannot restart — the fault that once took down ticket creation. And a routing failure must never cost the visitor the session they just opened. assignExistingTicket takes an id because the caller's entity is detached by then, and decoders a ticket somebody already holds — re-routing one out from under an agent already answering it would be worse than doing nothing.