Move the pool-availability recount after commit

Fixkamo-shared-library
Shipped
August 20, 2026 at 9:53 PM UTC
Author
Kamo
Commit
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.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing