Correct what the add-on binding gap actually was in production

DocsInitializerService
Shipped
August 23, 2026 at 5:44 AM UTC
Author
Kamo
Commit
779b722

The previous commit's reasoning was inferred from the loader, not measured. It claimed every KamoCRM add-on row had service_type NULL and that hosted mail was therefore unreachable. Checked against production on 2026-08-22, that is wrong: most rows had been bound by some earlier path, EMAIL_HOSTING among them, so hosted mail worked. Exactly one row was unbound — EMAIL_3P_INTEGRATION — which was still a real fault, since it is sold per seat and granted no mail app. That row has now been bound with this runner's own statement, so the runner is a no-op on the next run. No behaviour change. The code was right for the right reason; only the story around it overstated the blast radius, and a false narrative in a javadoc costs the next reader more than no narrative at all.

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