@udi-moshe_0021 sounds like it was a temporary outage on npmjs.org or perhaps even your proxy server. I wouldn't worry about it if it's working now since it's not something you could really control anyway

Hi @parthu-reddy, Thanks for discovering/confirming that; unfortunately we're not able to reproduce this issue, as the multi-part / chunked uploads already take into account multiple servers. Chunked upload sessions are persisted in the shared database (ChunkedUploads table) Bytes are appended to a file stored in shared store Would you be able to dig into the request patterns a little more? I suspect there's "something" configured on the load-balancer that's "doing something weird" with these ranged requests. The Multipart Upload API explains what's happening behind the scenes, and you may find that using pgutil assets upload is easier to troubleshoot. Thanks, Steve

Hi @it_9582, First and foremost, we don't recommend the "package promotion" feature as a means to indicate which "stage" (i.e. tested quality) a package is in relative to a CI/CD pipeline. Instead, repackaging should be used: https://docs.inedo.com/docs/proget/packages/repackaging Having multiple feeds is fine; we do that for Products and PreReleaseProducts on proget.inedo.com, but that's to make it "harder" for someone to accidently use a prerelease version. Otherwise, you can just use one feed and have retention policies cleanup the "-ci" builds. As for having the "build promotion" feature in ProGet be used as a workflow engine (i.e. to trigger actions upon promotion), I don't think we would consider that. At the most, we would do a webhook of sorts... though it doesn't make a ton of sense to be honest. The reason is that ProGet isn't intended as the "source of truth" for build status - the idea is that you would have something like a pipeline in BuildMaster) update the statuses in ProGet. The main benefit to having this status in ProGet is retention of builds/SBOMs. Hope that helps, Steve

Hi @stevedennis, thanks for your reply, it would be really nice if this feature could be implemented. We would chat about this with our point of contact. Thanks, Florian

Hi @alexvanini_5999 , I would try using the Inedo Agent instead; if you are getting this error, it most certainly means that there is some kind of security/hardening/account setting that is blocking WinRM. This is the underlying technology that PS Remoting and the PowerShell-based agent use. In this state, it's a real pain to get working - and the Inedo Agent is much more stable, anyway. It will not be "randomly blocked" by a new GPO or Patch Tuesday bug as we've seen a lot with WMI. Otherwise, you'll need to scour the web for obscure settings that may have been applied to the server. You may see information logged on the target machine under Windows Event Log under Windows Logs → Application or System related to WinRM. It's possible that the domain account lacks needed rights, even though it's a local admin. Sometimes subtle rights (like SeRemoteInteractiveLogonRight, etc.) can block initialization. Good luck, let us know what you find! Thanks, Steve

Oh ok, I was thinking that we could create a private metadata provider if we want deprecate our own packages without doing it on each feeds. So it will not help me. Thanks

@aristo_4359 oh I see! The "search" function does not work by version in that case

Hi @rob-leadbeater_2457, I'm afraid a "search by file hash" isn't supported, but you could relatively easily write a script to iterate through the feeds using pgutil. Or you could just search in the databse as well (FeedPackageVersions_Extended). Thanks, steve

@atripp Ahh ok, maybe that was what fixed it :)

Thank you

Hi @pmsensi , Can you take a look at this thread? https://forums.inedo.com/topic/5493/request-for-creation-of-api-for-package-auditing-before-dependency-restoration/7 I believe that new API proposal ( pgutil packages metadata) would contain that information -- please share your thoughts in that thread so we can keep it in one place. Thanks, Steve

Hi @wechselberg-nisboerge_3629 , Given how you uploaded the file, the only scenario that I could see this happening is if the file on disk is somehow corrupted. For example, if you were to locate one of the .rpm files on disk and change a few bytes with a hex editor, I would expect this exact error to occur. A feed reindex could would never fix this and obviously files cannot "heal themselves". However, this is exactly how hardware behaves, so I would look into that. Thanks, Steve

Hi @m-ruf_4197, Sure thing! I have added ticket PG-3115 to track the feature. It should be released within the next couple of maintenance releases of ProGet. Thanks, Rich

Hi @wechselberg-nisboerge_3629 , These specific errors would have no impact on performance, feed loading, nor would they cause ProGet to "break down" in any manner. And rebooting would most definitely not help, since they stem from bad/corrupt data. One possibility is that you have bad hardware - that causes peculiar and sporadic errors just like these that cannot be reproduced,. I can only imagine how frustrating this is, but your experience is atypical and without reproduction cases we really don't know how to help. I would focus on trying to reproduce -- if it's indeed "bad data" that you are uploading, it would happen every single time. Thanks, Steve

@albert-pender_6390 great news! And thanks for the heads up, I just updated the docs

Hi @wechselberg-nisboerge_3629, I'm not sure what I'm looking at in the screenshot, but it's most certainly not a piece of process memory. Based on the string literal, it's likely a compiled library (i.e. DLL) that's invoking methods in that system library; you'd need to study the contents in a hex view look for executable headers if you really wanted to know. Anyway, when it comes to downloading files, those are streamed directly from disk. In every instance of "corrupt downloads" that we've encountered, it was either due to network errors or hardware failures. And those are equally "impossible" to reproduce and nearly impossible to detect. I would just try new hardware, that usually does the trick. We see this quite a bit in cloud environments (Azure mostly, but every now and then AWS and GCP). Thanks, Steve

Hi @mmaharjan_0067 , It sounds like you're on the right track with researching this; your reverse proxy is definitely "breaking things" somehow. Based on what you wrote, it sounds like your reverse proxy is terminating the request because there's no output from the server after a while. The "no output" is expected, since assembling the upload takes quite some time, and that's likely where the "operation cancelled" would be coming from. I would look there and see if you can adjust timeouts. As for pgutil, here's the code used to perform the multi-part upload: https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L197 -- Dean

Thanks for the further info - I'll make sure we retest with Server 2025.

Hi @shijiyong_6709 , This is a known limitation; when we implemented our Maven2 feed, we followed the 20+ year old Maven rule that "versions begin with numbers, artifacts begin with letters". Unfortunately there are some "ancient artifacts" and "broken versions" that don't follow this rule. Since ProGet is not just a "dumb file server", knowing whether Arabba-SR13 is a version or artifact is important - and it's a nontrivial effort to address these "bad" artifacts. We will consider doing that in the future but it doesn't seem to impact a lot of artifactsa nd hasn't been a priority Thanks, Steve

@atripp Hi Alana, I've just updated our clusters and replication to S3 with files greater than 2 GB in size works fine now. Thanks for giving this your attention!