- Expédié
- 20 août 2026 à 21:53 UTC
- Auteur
- Kamo
- Commite
- 811db57
createLead a sauvé l'avance et puis, dans la même transaction, a été exécuté countAssignablePool pour diffuser le nouveau chiffre "Leads Disponible". Sur YugabyteDB a lire après une écriture dans la même transaction retourne 40001 "Redémarrer la lecture requis (la couche de la rechy retry n'est pas possible car ce n'est pas la première commande dans la transaction)", ce qui ABORTS la transaction (25P02). Les prises qui l'entouraient ont enregistré "La disponibilité publication en panne" et s'est déroulée Mais la transaction était déjà morte, donc chaque déclaration ultérieure a échoué et le commit est revenu comme "marqué comme roll-back-only". Une publication documentée comme "jamais fatal" a détruit silencieusement l'avance qu'il venait d'écrire. Une prise de 789 lignes run Los 101 aboutit à cela et a dû refaire, ce qui est aussi la façon dont il a été trouvé. Reporté à l'après-Commit() via l'appariement peut-être PushToLos dans cette même classe, avec un repli en ligne quand aucune transaction est actif. Seules les clés scalaires sont capturées - après l'engagement du plomb est détachés. Le chiffre est aussi tout simplement plus correct: pré-engagement publié, il Annonce d'un comptage qu'aucun autre lecteur ne peut encore voir. Affecte chaque créateur de créationLead: le magicien d'importation, les points d'extrémité d'entrée en plomb, le webinaire public/la forme d'adjument, l'API et le consommateur social.