Resolve contexts and credentials through real accounts

Round two of review on the accounts layer.

The settings picker mapped its legacy instance-keyed selection straight
onto DataContext(legacy:), which turns an instance UUID into an account
UUID. That identity only holds for migrated accounts - a login created
after the revamp has a random ID - so selecting a freshly added account
named one that does not exist and left the provider nil. Selections now
resolve through AccountsManager to an actual account on that instance,
preferring a signed-in one. The picker still lists one entry per instance
and so cannot show a second login; the Phase 3 switcher replaces it.

BackgroundFeedRefresher was missed in the previous sweep because it
resolves credentials differently: it routed on the legacy setting and
looked up "first enabled Invidious instance" with an instance-keyed
credential. After any new-style login that silently found nothing and
skipped the refresh. It now routes on the selected context and takes the
credential from that account.

Subscription reads used the raw stored context, so an account waiting on
its instance or credential rendered empty instead of falling back to local
data as the tri-state design specifies. Reads go through the validator's
effective context; writes deliberately do not, so a subscribe fails
visibly rather than landing in local data the user did not choose.

Account statuses are cleared when the identity namespace reloads, but
nothing recomputed them once a deferred scope resolution succeeded - a
synced account kept showing "sign in required" until relaunch. The scope
change now triggers a refresh, deferred by one turn so it cannot depend on
observer registration order relative to the store's own reload.
This commit is contained in:
Arkadiusz Fal
2026-08-24 23:59:46 +02:00
parent 2fded2e1dd
commit bef119f70e
6 changed files with 136 additions and 22 deletions

View File

@@ -206,7 +206,9 @@ struct SubscriptionsSettingsView: View {
// the last readers of it. Letting them diverge would show one account
// in the UI while serving another's data.
settingsManager?.subscriptionAccount = newAccount
appEnvironment?.accountsManager.setContext(DataContext(legacy: newAccount))
appEnvironment?.accountsManager.setContext(
appEnvironment?.accountsManager.context(forLegacyInstanceID: newAccount.instanceID) ?? .local
)
SubscriptionFeedCache.shared.handleAccountChange()
// Trigger feed refresh in background