Thanks for the additional debugging information; we now see why this doesn't work. It would appear that NuGet stopped streaming all versions of the packages at some point, and now appends the following at the end of its package search XML... <link rel="next" href="http://www.nuget.org/api/v2/Packages? $filter=tolower(Id)%20eq% 20'ravendb.client'&$orderby=Id& $skiptoken='RavenDB.Clie nt','RavenDB.Client','1.2.2005-Unstable'" /> So, we will need to add support for this as well... I've added this as PG-140, but it's not scheduled for a release yet. If an enterprise (i.e. paying) user requests this, we can expedite it of course.

Hi @gurdip-sira_1271, Yes, this will be released with Otter later today. Thanks, Rich

Please review KB#1161 for instructions on how to update this.

Hi @aries66_2180, I just set up a clean ProGet 6.0.16 docker instance and tested this and it seems to be working for me. Can you send me an example image you are trying to push that fails? Also, would you be able to use a tool like WireShark or Fiddler to record your requests when trying to push an image and email it over to us at support@inedo.com with a subject of [QA-878] Docker push error? Thanks, Rich

We take problems very seriously, but we need to prioritize where to spend engineering resources tracking down problems. This was a edge case that we could not reproduce, and had a very minor impact, and only affected a very small number of free users with a very specific configuration; a free user was able to track down the underlying cause and we fixed it.

We haven't heard any other complaints, so it leads me to think it's either your end (proxy?) or npm's end (blocking). We have no idea what their blocking mechanism could look like. For all we know, they could be doing agent-string filtering, and blocking requests from ProGet software, but not your web browser or npm client. Best bet is to run ProGet through a proxy (like fiddler or wireshark), by going to Admin > Proxy. Then you can see exact traffic.

Hi @pfeigl, Thanks for letting us know. It looks like this is related to how HEAD requests were handled. I went and added that header to head requests also. This will be tracked in PG-2300 and will be released in ProGet 2022.25. Thanks, Rich

Hi @marc-ledent_9164, Ah, thanks for the extra details here. I was finally able to recreate this issue. I'm tracking the fix in BM-3770 which is expected to release in the next version of BuildMaster, which is due out this week. Thanks, Rich

Good news

Hi @scusson_9923, Glad to hear it! Thanks for following up as well! Thanks, Rich

I'm directly executing the DashboardFeeds view, so I'm not using the parameter. It seems that the SUM([Package_Size] for [Feed_Size] and [Cache_Size] are the culprit. When I replace the query with [Feed_Size] = 0, [Cache_Size] = 0 then the timeouts are gone! They are just missing from the feed disk usage graph. Adding an index to NuGetPackageVersionsV2.Package_Size didn't help. The strange thing is that some pages that are not using the graph are also executing the DashboardInfo stored procedure.

@atripp Thanks, I installed 23.0.10 this morning and the git checkout task succeeds on the RedHat server. Next step is getting the docker build task to succeed. I may open a separate post for that.

For completeness, v3.0.3 was just published which adds an index to Publish_Date and the dashboard query now returns virtually instantly tested against 100,000+ packages in the database.

Hi @claudio_9251, I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that. Thanks, Dan

Just wanted to let everyone know who's affected by this that we have a fix in 3.5.0. It's officially classified as a beta version, but only due to some database schema changes. The release notes and download links are here: http://inedo.com/proget/versions

Unfortunately we're not able to diagnose this with the information you provided. That error really doesn't make sense in the place it's happening. Can you please submit a ticket with: Configuration Variables defined at various levels (System, etc) Plan as OtterScript Pipeline as JSON Full Execution log, including the full stack trace you sent

Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know. But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that. There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.

Thanks! We will have this fixed in ProGet 4.0.14, which will be released within the hour.

hi @scroak_6473 , just to let you know, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10 Getting LDAP/LDAPS to work on Linux was a whole different problem to solve; the three major libraries (DotNetCore, Mono, Novell) all had separate and strange bugs. We'll be blogging about this, but for now, it might be a step in the right direction for addressing the problems you're seeing, at the very least.

Thanks I made a backup and ran the script and it did clean up quite a few rows. I'll try upgrading to 2024 again next week after we released :)