Gating activation on a live config response turns a brief outage into a configuration error

Trace the launch in the example the post uses. A .NET MAUI wrapper hosts a Blazor UI. The startup layer probes reachability, gets nothing, and carries on, because the network can be absent and a failed probe should not prevent launch ^[2]. The layer above calls the runtime-configuration endpoint and will not activate the application scope without a successful answer ^[3]. Each layer is defensible alone, and the post says that together they disagree ^[6]. It writes the disagreement as two sentences: the lower layer says "reachability is not a launch gate", and the higher layer says "no live response, no ready state" ^[5].

Classification comes before storage. In the post's four-step order the cache is consulted third, after the failure has been classified ^[9][25]. "Not every failed request grants permission to use stale data," the post says ^[23].

The two failure classes call for different answers. A timeout, a lost connection or a temporary server error says "the current answer is unavailable", and a recent cached configuration may be the best safe answer ^[10]. An authoritative not-found or gone says "this configuration no longer exists here", and serving the cache there overrides current server knowledge with old local knowledge ^[11]. "That is not resilience; it is refusal to accept invalidation," the post says ^[12].

Even with a transient failure, the cached entry has to pass four checks first: it must belong to the same logical scope, come from the same configured source, sit within a deliberate age bound, and not be timestamped implausibly far in the future ^[13]. Source binding is the one the post says is easy to miss, because runtime configuration often contains addresses and capability switches, so an app that has been repointed while still serving a cache from the old source "may look healthy while sending work to the wrong place" ^[14]. The clock rule exists because a future-dated entry can otherwise stay fresh far longer than intended ^[16]. The age bound is a product and operational decision, and the post asks that the reasoning be written down so the next engineer knows whether changing it is a reliability decision or a cosmetic edit ^[15].

Reconnect is the expensive part. Rerunning the whole startup pipeline may advance a session epoch, cancel in-flight requests, clear actor state, restart background rails and remount the renderer ^[18]. On a flapping connection that cost recurs ^[19]. The renderer gets torn down and remounted to discover that the configuration has not changed. The post prefers an in-place refresh while the current scope is still valid: update the runtime configuration, clear the refresh hint, and let the active session continue, escalating to full resolution only when the refresh proves the scope disappeared or changed in a way that makes continuity unsafe ^[20]. An app that opened from fallback data should be carrying that explicit "needs refresh" hint in the first place ^[17].

Two conditions have to hold for any of this to transfer to your codebase: a layer that can activate or withhold a scope, and control-plane data fetched during startup. The post says the same invalidation rule is needed for offline permissions, feature manifests, routing metadata and other control-plane data ^[22]. It cites no incident and gives no figures. It asks for five named states and the events between them: uninitialised, resolving, ready from live data, ready from fallback data, unavailable ^[7][8].