-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[Collections] Removed local package collection comes back alive #3617
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
Conversation
Steps to reproduce: 1. Add a local collection 2. Delete the collection **file** on local disk 3. Refresh collections 4. The unavailable local collection is back! This is caused by us not deleting unavailable/invalid collections from storage when refresh fails. rdar://80388968
@swift-ci please smoke test |
@@ -454,16 +454,16 @@ public struct PackageCollections: PackageCollectionsProtocol { | |||
private func refreshCollectionFromSource(source: PackageCollectionsModel.CollectionSource, | |||
trustConfirmationProvider: ((PackageCollectionsModel.Collection, @escaping (Bool) -> Void) -> Void)?, | |||
callback: @escaping (Result<Model.Collection, Error>) -> Void) { | |||
if let errors = source.validate()?.errors() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have the same logic in the provider. Removing this so we don't have to duplicate storage removal logic (i.e., L464-466) here.
what is the expected behavior if the collection is on the network and there is a network issue? i.e. the refresh fails because it cant reach the server.... would deleting the collection still make sense? |
The collection URL remains in the config file so on next refresh it will become available again if the network issue goes away or the local file is placed back. |
We can distinguish between a) bad local file, b) not found (404), and c) unavailable (non-404 error codes) such that we only remove from storage in cases (a) and (b). Do we want to do that? But then, we can't tell in case of (c) if it's temporary or permanent. |
if the next refresh will try to fetch again (since still in config) it I think its fine, no? |
@swift-ci please smoke test Linux |
the linux CI failure seems like a regression in driver, other PRs are failing the same way cc @artemcm |
@swift-ci please smoke test linux |
Steps to reproduce:
This is caused by us not deleting unavailable/invalid collections from storage when refresh fails.
rdar://80388968