- Spegnimento
- 9 settembre 2026 alle ore 03:18 UTC
- Autore
- Kamo
- Impegno
- 0fb31d6
ServiceTypeConverter ha smesso di lanciare su un id app sconosciuto e ha iniziato a risolverlo a null, che è ciò che un servizio deve fare — le navi enum dentro ogni vaso mentre il catalogo è condiviso, quindi una nuova applicazione è sempre nel database prima che l'ultimo lettore abbia è stato ricostruito, e gettare lì ha preso tutto il catalogo giù il 2026-09-08. Ha anche fatto due righe diverse leggere allo stesso modo. Una riga caratteristica senza service type è copia di marketing — conta sedili, SLAs, support tiers, 38 delle 98 righe in diretta, 2 delle 15 componenti aggiuntivi — e appartiene ad ogni carta. Una riga che nomina un'app che questa costruzione non può identificare è uno la cui disponibilità non può essere richiesto. èSellable leggere sia come null e ha risposto "mostrarlo", così la prossima app id aggiunto prima di una ricostruzione non sarebbe schiantare catalogo più; sarebbe tranquillamente pubblicizzare un'app non autorizzata su ogni carta di piano e nella lista add-on. Questo è l'esatto fallimento che il controllo di disponibilità esiste per prevenire, arrivare silenziosamente invece di rumorosamente. L'attributo convertito non può distinguere i due, quindi CatalogAppBindings legge i raw service type colonna e risposte che le righe nominano un app affatto. Un query nativo in la forma OrgDirectoryRepository utilizza già qui, piuttosto che una seconda mappatura la colonna sull'entità bibliotecaria condivisa: nessun test in questo servizio può avviare Hibernate per dimostrare una tale mappatura, e un servizio di fatturazione che si blocca è peggiore del difetto. Sette test indicano la decisione a tre vie su entrambe le superfici, compresi i due che ha fallito prima di questo cambiamento.