Login State Fans Out To Settings

Withdrawing a credential is a fan-out, not a field write

Logging out looks like one line: clear the stored credential. It is not. Around that credential sits everything the app derived from it or gated behind it — a feature switch the user turned on, a cached access token and the timestamp saying when it expires, a per-feature sub-switch, a cached profile name shown in the settings entry. Clearing only the credential leaves all of it behind, pointing at an account you no longer have.

The state that survives is worse than useless, because it is inconsistent in a direction the user cannot fix: a feature switch gated behind "logged in" greys out when the user logs out, so the switch reads ON and refuses to be turned OFF. Only code can clear it now, and the code that should have is the logout you just wrote.

Do the fan-out where the credential is withdrawn:

// adapted — names generalized; the source spells this as a login setter taking false, so its state
// emit is folded into the refresh here; a second derived-token/expiry pair and a settle delay elided
fun logOut() {
    viewModelScope.launch {
        settings.setCredential("")
        // Everything gated behind that credential comes down with it. Otherwise the sub-switches
        // stay stuck ON with no way to switch them off (they grey out when logged out) and stale
        // derived tokens linger.
        settings.setFeatureAEnabled(false)
        settings.setFeatureBEnabled(false)
        settings.setDerivedToken("")
        settings.setDerivedTokenExpires(0)
        refreshLoginState()
    }
}

Traps

There is more than one way to lose a credential, and only one of them is a button. The user can log out; the service can also revoke the session, which your client discovers as one specific error code on an ordinary call. The revocation path must run the same reset, or every symptom in this skill appears without anyone having touched the logout button — and it is much harder to reproduce, because the trigger happened on someone else's server. Route both paths through one function rather than clearing the credential in two places:

// adapted — names generalized
if (error.needsReauth) {
    // Clearing the stored session puts the settings entry back to "log in" instead of the feature
    // silently doing nothing forever.
    settings.clearSession()
}

A UI-level auto-disable is not a substitute for the choke point. A settings row that turns its own switch off when its gate goes false (nested-flag-settings-auto-disable) only runs while that screen is composed. Log out from somewhere else, or have the session revoked in the background, and nothing runs — the flag stays on until the user happens to open settings again. Where a codebase has several integrations, this is usually why one of them looks fixed and another does not: they were fixed at different layers.

Two failure shapes, and the quiet one is worse. If the consumer gates correctly on the credential, a stuck flag produces a feature that is on and does nothing, indefinitely, with no error — the user believes it is working. If the consumer does not gate, the same stuck flag produces a call against an empty credential on every tick, which at best floods the log and at worst becomes an endless authentication retry (retry-needs-backoff-and-cap). Both need fixing, and the silent one will not be reported.

Gate the consumer as well, and derive the gate from both facts. The reset is the cure; the gate is the seatbelt, and it also closes the window between the credential being cleared and the flag being written. Combine the switch and the credential into one derived boolean and let the subsystem follow it — see combine-two-flags-to-gate for the shape and for making both branches idempotent.

Clear the derived artifacts too, including their expiry stamps. A cleared session next to a still-valid cached token is a state no code path expects: the credential check says logged out while the cached token still works, so behaviour depends on which one a given call happens to read. Clear the token and the timestamp that describes it in the same write, and treat "session cleared" as implying "everything minted from that session is void".

Refresh whatever the UI reads, after the writes. If the screen's state comes from a snapshot rather than a live subscription to the stored values, the fan-out is invisible until the screen is re-entered — which looks exactly like the bug you just fixed. Prefer a subscription; if you must refresh imperatively, do it last, after every write has landed.

Enumerate the dependents mechanically, not from memory. The list is longer than it feels, and each integration has its own. Grep for the gate before writing the logout, and again afterwards — and grep for the withdrawal, not for the word "logout", because a codebase that models login as a boolean setting spells its logout setLoggedIn(false) and hides it from every verb-shaped search.

Verifying it

List every logout entry point, then every setting whose enabled-ness is derived from a login state, then for each gated setting find the logout path that resets it. A logout is frequently not a verb-named function at all — it is a state setter called with false, or a bare credential-clearing write — so searching for the verb alone inverts the answer, reporting that the integration with the most complete fan-out has no logout entry point whatsoever:

grep -rnE "fun (logOut|logout|signOut)|clearSession" --include="*.kt" . | grep -v "/build/"
grep -rnE "fun set[A-Za-z]*Log[A-Za-z]*\(" --include="*.kt" . | grep -v "/build/"
grep -rnE "set[A-Za-z]*(Token|Session|Cookie|Credential)\(\s*([a-zA-Z]+ = )?\"\"" \
  --include="*.kt" . | grep -v "/build/"
grep -rn "isEnable = \|enabled = " --include="*.kt" . | grep -v "/build/"
grep -rn "needsReauth\|invalidSession\|reauth" --include="*.kt" . | grep -v "/build/"

The first three are one list between them: the verb, the login-state setter, and the write that actually clears the credential. Read them together, and expect the same logout to appear in two of them. The last command finds the revocation path. If it returns nothing, your client cannot tell a dead session from any other error, and the fan-out has exactly one trigger where it needs two.

Behaviourally, for each integration: turn on every sub-switch it offers, log out, and reopen the settings screen. Every switch must read OFF and be interactive again. Then repeat without opening settings — log out, force-stop, relaunch, go straight to the feature. It must be off. Finally, revoke the session from the service's own account page while the app runs, exercise the feature, and confirm the app returns to a logged-out state rather than failing on every call.