Symptom

After a peer TLS certificate was fetched and written to disk, rebuildHttpClient()rebuild()reload() always logged “Reloaded trust material” at INFO level regardless of whether any certificates were actually loaded. If the freshly written cert file was corrupt or unparseable, the trust store silently became empty and all subsequent TLS connections to peer servers failed with cryptic SSL handshake errors. The only diagnostic was per-cert logger.e lines buried in buildTrustManagerFromTrustedCerts, with no summary at the rebuild() call site.

Root cause

buildTrustManagerFromTrustedCerts returned X509TrustManager — a single type with no way to convey how many certs were actually loaded. The loaded-cert count was a local variable that evaporated when the function returned. ReloadableX509TrustManager.reload() returned Unit; HttpClientProvider.rebuild() therefore had no signal to distinguish “loaded 1 cert” from “loaded 0 certs because all files were corrupt”. It emitted a cheerful logger.i("Reloaded trust material") in both cases.

This was a residual gap left by PR #381 (which added the per-cert warning log) and PR #532 (which introduced the in-place reload pattern). PR #381 fixed the inner diagnostic; this issue fixes the propagation up the call stack.

Fix

Prevention