Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Artifacts getting removed from Database after FeedCleanup Scheduled task run
-
I had setup a new setup of Proget with datastore on S3 and it was set to replicate from another server (old setup) with datastore on disk (Windows local filesystem) using Feed Replication. I had 2 feeds to be replicated over from the old setup to the new setup which did get replicated and all the artifacts did got copied over for both the feeds after which they were in sync.
But a day after I discovered that a majority of my artifacts were not showing up on the new setup UI and the total count of packages was also 1/3rd of what it was day before. Also checked my database, the packages are also removed from it was well. But all the packages are present on the S3 bucket.
Turns out Schedule task FeedCleanup ran and identified most of my packages as orphaned and removed them from the database.INFO: Checking for orphaned package index entries... DEBUG: Found 133575 orphaned package entries. DEBUG: Removing Id='abc',Version='1.0.168' from index... DEBUG: Removing Id='abcd',Version='1.0.66' from index...Running the FeedCleanup again was of no help and did not add the missing packages back.
I wish to understand
- What does this FeedCleanup Schedule task does AFAIK is remove artifacts from the filesystem in case of missing metadata on DB.
- Why were my artifacts removed in the first place from the database.
- How do I go about restoring these artifacts since the artifacts are still present on the S3 bucket without essentially copying them again.
- Can I disable this scheduled task to avoid such instances of package removal? Are there any side effects of disabling this task. ?
Let me know if any further details are needed from my end.
Thanks !!Product: ProGet
Version: 4.5.3 -
Copying from associated support ticket:
It's not a bug per se, more of a design flaw with the introduction of external package stores. Basically, it checked to see if the package could be opened and if not, deleted it from the DB. However, there are many reasons a package might not be accessible (network down, invalid S3 credentials, disk inaccessible, S3 down, etc.), so this functionality was removed since then.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login