- Shipped
- 6 noiembrie 2026 la 18:31 UTC
- Author
- Kamo
- Commit
- 5b273d8
Apel Podea rezultat presă, profilat cu JFR pe un SecurityService pod (lab org, 40 prese): Scrierea /stage a durat 160-360 ms, median ~220 ms, din care aproximativ 90 ms au fost urmăririle post-commit Nimeni nu așteaptă: trackerul de contact (eticheta de stare citit + 2-3 upserts, fiecare cu propriul YugabyteDB Un serviciu care declară noul client (commit) și urmașul conductei (o a doua încărcare completă a lead-ului) Executorul LeadStatusFollowUps răspunde acum odată ce starea s-a angajat și rulează cele două pe ea; Fără unul, ele rulează în linie ca înainte. Stop All Outreach și callback-ul datorat rămân închise Sincron. Planificatorul YugabyteDB este euristic: "org_id = ? AND <cheie>" merge prin indexul organizației Cel mai mare org (EXPLAIN ANALYZE, read-only): - istoricul lead-urilor pe lead: 17.9 s -> 35 ms. Citirile pe lead se fac prin lead_uid, org verificate prin cheie. - DialLedger primul text de conducere citit: 7,15 s -> ~ 1,5 ms (numai UID, org verificat în Java). - **************** de uid numai, org verificat în Java (acces de înregistrare, etichete). - grila /leads cu leaduri numite (fila selectată, fluxul de leaduri): org check scris org_id + 0 = ?, 7.06 s -> 4.6 ms; acelasi filtru, nici un index nu il poate deservi, asa ca se foloseste pk.