- Shipped
- September 9, 2026 at 3:18 AM UTC
- Author
- Kamo
- Commit
- 0fb31d6
ServiceTypeConverter stopped throwing on an unknown app id and started resolving it to null, which is what a service must do — the enum ships inside each jar while the catalog is shared, so a new app is always in the database before the last reader has been rebuilt, and throwing there took this whole catalog down on 2026-09-08. It also made two different rows read alike. A feature row with no service_type is marketing copy — seat counts, SLAs, support tiers, 38 of the 98 live rows, 2 of the 15 add-ons — and belongs on every card. A row naming an app this build cannot identify is one whose availability CANNOT BE ASKED. isSellable read both as null and answered "show it", so the next app id added before a rebuild would not crash the catalog any more; it would quietly advertise an unreleased app on every plan card and in the add-on list. That is the exact failure the availability check exists to prevent, arriving silently instead of loudly. The converted attribute cannot tell the two apart, so CatalogAppBindings reads the raw service_type column and answers which rows name an app at all. A native query in the shape OrgDirectoryRepository already uses here, rather than a second mapping of the column on the shared-library entity: no test in this service can boot Hibernate to prove such a mapping, and a crash-looping billing service is worse than the defect. Seven tests pin the three-way decision on both surfaces, including the two that failed before this change.