-
Notifications
You must be signed in to change notification settings - Fork 166
Podcast Re-subscription fixes #3550
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
Ensure sync progress notifications always fire: Wraps importPodcast’s progress counter updates in a defer so every exit path still posts syncProgressPodcastUpto and syncProgressPodcastCount, preserving UI accuracy when we return early.
This allows us to more easily bail out with early returns in cases where we may want to (podcast is deleted or unsubscribed)
Respect server subscription intent for new podcasts: Adds a derived shouldSubscribe flag and passes it through to addFromUuid, preventing re-subscribing podcasts the server reports as unsubscribed. We could also short-circuit the addFromUUID call on shouldSubscribe being false but I figured we may be better off keeping that functionality as is.
Uses the subscribed value instead of updating to isDeleted. This should help in case we only receive subscribed and not isDeleted. We won't want to set subscribed to 0 when isDeleted is missing but subscribed is 0
This behavior was changed a bit last minute to keep the podcast in the DB with the subscribed value set rather than skipping adding it.
|
Version |
|
@bjtitus and I tested this together and we think this PR needs some extra checks to see if all the logic is solid taking in account our server implementation for sync |
|
Version |
|
@bjtitus are you still looking into this? Should I remove myself as reviewer? |
Fixes PCIOS-175
There are two primary fix attempts here:
shouldSubscribewhen we callserverPodcastManager.addFromUuid. Otherwise, we could potentially subscribe to a Podcast which the server already told us is unsubscribed.subscribedbased on theisDeletedvalue. It seems like we should also usesubscribedif only it exists. I'm not 100% sure on why we ever useisDeleted, but I decided to keep that for now. It only happens in specific cases wherecheckIsDeletedistruebut this might be something to look at in the future.So both fixes really come down to using the server's
subscribedvalue where we weren't before.To test
Checklist
CHANGELOG.mdif necessary.