Move the pool-availability recount after commit

Fixkamo-shared-library
Ya
20 Agosti 2026, 21:53 UTC
Mwandishi
Kamo
Ahadi ya
811db57

createLead saved the lead and then, in the same transaction, ran countAssignablePool to broadcast the new "Leads Available" figure. On YugabyteDB a read after a write in the same transaction returns 40001 "Restart read required (query layer retry isn't possible because this is not the first command in the transaction)", which ABORTS the transaction (25P02). The catch around it logged "Pool-availability publish failed" and carried on — but the transaction was already dead, so every later statement failed and the commit came back as "marked as rollback-only". A publish documented as "never fatal" was silently destroying the lead it had just written. A 789-row intake run lost 101 leads to this and had to re-run, which is also how it was found. Deferred to afterCommit() via **************** matching maybePushToLos in this same class, with an inline fallback when no transaction is active. Only the scalar keys are captured — after commit the Lead is detached. The figure is also simply more correct there: published pre-commit, it announced a count no other reader could see yet. Affects every createLead caller: the import wizard, lead-intake endpoints, the public webinar/demo form, the API and the social consumer.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei