Mirrored_Repos/yattee
1
0
Fork 0
mirror of https://github.com/yattee/yattee.git synced 2026-11-04 19:07:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

Only a deletion the app can point at moves the selection

Browse Source 
`correctIfContextRemoved` read a locally missing account as a deleted one
and reset the context with `setContext(.local)` — a new timestamp and a
pending upload. Now that foreground activation calls it, it ran before
the fetch that delivers the account record: a perfectly good remote
choice was reset and then published over everybody else's. It now asks
`AccountsManager` for a repair keyed on the deletion tombstone, which is
the same repair a deletion performs — a signed-in login on the same
server when there is one, the replaced choice's timestamp, nothing
uploaded. The toast names where the selection actually landed.

Adopting a synced context that named a deleted account repaired it but
kept whatever upload the previous choice still owed, so the sync engine
published the automatic fallback under that choice's timestamp — exactly
what not stamping it "now" exists to prevent. The adoption clears the
flag, and only on adoption: a local choice that outranks the repair keeps
its own upload.

The channel button's subscription lookup is fenced to the channel and the
round it was asked in, so an answer that lands after the user has walked
on — or after the account behind it changed — no longer writes itself
into the button on screen. Context and credential changes ask again. A
destination toggle is compared against the effective context rather than
the raw selection: the menu offers Local precisely when the selected
account cannot be written to, and that toggle has to be the one the
button then shows.

The destination rows forget their checkmarks when the logins change. The
answers describe credentials that have been replaced, and the tvOS picker
deliberately stays open across exactly that.

The subscriptions settings screen counts and exports what it is actually
reading from. The fetch behind both already followed the effective
context while the branch and the footer followed the selection, so an
unavailable account meant local data described as the server's.

The legacy `subscriptionAccount` migration refused to adopt a context
whose account had not synced yet and was never retried, leaving a fresh
install on local until the next launch. A synced account arriving now
retries it; the migration's own guards keep it a one-way move that never
overrides a choice made in the meantime.

The remaining negative-able Piped counts — likes, channel subscribers and
videos, playlist video counts — go through `PipedSentinel.count` like the
views and upload dates already did.
This commit is contained in:
Arkadiusz Fal
2026-09-04 23:56:39 +02:00
parent 69179c9fe9
commit fbeae586b0
8 changed files with 350 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
Yattee/Views/Channel/ChannelView.swift
View File

@@ -29,6 +29,10 @@ struct ChannelView: View {
@State private var isLoadingMore = false
@State private var errorMessage: String?
@State private var isSubscribed = false
/// Which subscription lookup the button state belongs to. A channel change
/// or a change of who is being read as bumps it, so a reply from the
/// previous one is dropped instead of answering for the channel on screen.
@State private var subscriptionGeneration = 0
@State private var showingUnsubscribeConfirmation = false
#if os(tvOS)
@State private var showingSubscriptionDestinations = false
@@ -196,6 +200,15 @@ struct ChannelView: View {
.onReceive(NotificationCenter.default.publisher(for: .watchHistoryDidChange)) { _ in
loadWatchEntries()
}
// Whose subscriptions the button speaks for just changed — by selection,
// or by the credential behind the selected account being replaced — so
// it has to be asked again rather than left showing the last answer.
.onReceive(NotificationCenter.default.publisher(for: .dataContextDidChange)) { _ in
refreshSubscription()
}
.onReceive(NotificationCenter.default.publisher(for: .accountCredentialDidChange)) { _ in
refreshSubscription()
}
}
/// Applies the channel `.searchable` field and its search handlers around the given
@@ -1324,8 +1337,13 @@ struct ChannelView: View {
/// A destination row toggled something. Only the account on screen changes
/// what the main button says, and notification preferences are local and
/// keyed by channel, so they follow the same rule.
///
/// Compared against the *effective* context, which is what the button reads
/// from: while the selected account is unavailable the button speaks for
/// local data, and the menu offers Local precisely so the user can act on it
/// — a toggle there has to be the one the button then shows.
private func destinationDidToggle(_ context: DataContext, subscribed: Bool) {
guard context == appEnvironment?.accountsManager.currentContext else { return }
guard context == appEnvironment?.dataContextValidator.effectiveContext else { return }
if subscribed,
appEnvironment?.settingsManager.defaultNotificationsForNewChannels == true,
@@ -2326,9 +2344,19 @@ struct ChannelView: View {
isSubscribed = appEnvironment?.dataManager.subscription(for: effectiveChannelID) != nil
}
subscriptionGeneration += 1
let generation = subscriptionGeneration
Task {
if let service = appEnvironment?.subscriptionService {
isSubscribed = await service.isSubscribed(to: effectiveChannelID)
let subscribed = await service.isSubscribed(to: effectiveChannelID)
// This view is reused as the user navigates from channel to
// channel, and the answer may have been asked for under another
// account entirely. Either way it no longer describes the button
// it would be written to.
guard generation == subscriptionGeneration,
(channel?.id.channelID ?? channelID) == effectiveChannelID else { return }
isSubscribed = subscribed
}
}
}

33
Yattee/Views/Components/SubscriptionDestinationMenu.swift
View File

@@ -104,6 +104,18 @@ struct SubscriptionDestinationRows: View {
@State private var membership = SubscriptionDestinationMembership()
@State private var busy: Set<DataContext> = []
/// Bumped when the logins change, so the answers are asked for again.
@State private var membershipRound = 0
/// What a round of membership answers belongs to.
///
/// The channel alone is not enough: the same channel on the same rows means
/// something different once a credential has been replaced, and the picker
/// deliberately stays open across such a change on tvOS.
private struct MembershipRequest: Equatable {
let channel: Channel.ID
let round: Int
}
var body: some View {
ForEach(destinations, id: \.self) { context in
@@ -121,9 +133,28 @@ struct SubscriptionDestinationRows: View {
// Membership is only asked for once the rows are on screen: an unwarmed
// provider answers by fetching that account's whole subscription list,
// which is far too much to spend on a menu nobody opened.
.task(id: channel.id) {
.task(id: MembershipRequest(channel: channel.id, round: membershipRound)) {
await loadMembership()
}
// The credential behind an account was replaced, or the accounts
// themselves changed: every checkmark on screen describes the logins
// that were there before.
.onReceive(NotificationCenter.default.publisher(for: .accountCredentialDidChange)) { _ in
invalidateMembership()
}
.onReceive(NotificationCenter.default.publisher(for: .accountsDidChange)) { _ in
invalidateMembership()
}
}
/// Forgets what is known and asks again.
///
/// Forgetting first, rather than waiting for the replacement answers: a row
/// toggled in between would otherwise toggle against the previous login's
/// membership and do the opposite of what its checkmark promises.
private func invalidateMembership() {
membership.invalidate()
membershipRound += 1
}
@ViewBuilder

27
Yattee/Views/Settings/SubscriptionsSettingsView.swift
View File

@@ -61,6 +61,16 @@ struct SubscriptionsSettingsView: View {
appEnvironment?.accountsManager.currentContext ?? .local
}
/// What the counts and the export are actually read from.
///
/// While the selected account is unavailable that is the local store — so a
/// count or a file described as the account's would name a source it never
/// came from. The selection itself is untouched, and the moment the account
/// is usable again this follows it back.
private var effectiveContext: DataContext {
appEnvironment?.dataContextValidator.effectiveContext ?? currentContext
}
var body: some View {
List {
accountSection
@@ -68,7 +78,10 @@ struct SubscriptionsSettingsView: View {
exportSection
localDataSection
}
.task(id: currentContext) {
// Keyed to the effective context, not the selection: an account going
// unavailable — or coming back — changes which store the count is read
// from without the selection moving at all.
.task(id: effectiveContext) {
await refreshAccountSubscriptionCount()
}
.navigationTitle(String(localized: "settings.subscriptions.title"))
@@ -282,11 +295,15 @@ struct SubscriptionsSettingsView: View {
}
}
/// Exports subscriptions of the active account: the local store in local
/// mode, or the server's list for Invidious/Piped accounts.
/// Exports subscriptions of whatever is being read from: the local store in
/// local mode, or the server's list for Invidious/Piped accounts.
///
/// The branch follows the effective context because the fetch below does —
/// branching on the selection instead would take the server path only to
/// export local data through it.
private func performExport() async {
let subscriptions: [Subscription]
if currentContext.isLocal {
if effectiveContext.isLocal {
guard let dataManager else { return }
subscriptions = dataManager.allSubscriptions
} else {
@@ -342,7 +359,7 @@ struct SubscriptionsSettingsView: View {
if let cached = subscriptionService.cachedSubscriptionCount {
accountSubscriptionCount = cached
}
if !subscriptionService.currentContext.isLocal {
if !effectiveContext.isLocal {
if let channels = try? await subscriptionService.fetchSubscriptions() {
accountSubscriptionCount = channels.count
}