@atripp @joshuagilman_1054

TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...

• [System.Nullable``1[[System.Int32]]]
• [Nullable[int]]

... much easier to read

You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.

The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.

Hi @jimbobmcgee ,

Thanks for all the details; we plan to review/investigate this via OT-518 in an upcoming maintenance release, likely in the next few two-week cycles.

-- Dean

Hi @andreas-unverdorben_1551 ,

npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.

Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.

So, a much less powerful server doing a lot more processing is going to be a little slower ;)

Running ProGet in a server cluster will certainly help.

Cheers,
Dean

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

Hi @kichikawa_2913,

We see multiple connectors pretty often, and it rarely presents a problem.

The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.

However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm feed wouldn't have any connectors.

Hope that gives some insight,

Dean

@joel-shuman_8427 thanks for the heads up!

I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

Hi mwatt_5816,

BuildMaster does support "release-less" builds, though you may need to enable it under the application's Settings > Configure Build & Release Features > Set Release Usage to optional. That will allow you to create a build that's not associated with a release.

It's also possible to do "ad-hoc" builds (i.e. builds with no pipeline), but we don't make it easy to do in the UI because it's almost always a mistake (once you already have pipelines configured). So in your case, I think you should create a secondary pipeline for this purpose.

-- Dean

Hi @jfullmer_7346 ,

I'm afraid I can't reproduce this data that lead to this error; I did manually hack the database to get it close to what your results showed (i.e. WinSCP and winscp) -- and I got an error the first re-index, but then it got fixed a second time.

At this point, it would require having your database and attaching a debugger to see what's going on. That's a bit more effort than we're able to spend today on a community / non-paid user today, especially given the trickyness of this bug.

HOWEVER -- since you're familiar with PostgreSQL, it might just be quicker to DELETE the duplicate / unused PackageVersionIds and PackageNameIds. That's what we had done in previous versions (2024 and earlier) when there was a problem. Once you have a single record, you can update the casing pretty easily.

Or if you don't care about any packages, just start a new instance of PRoGet and add the packages in. This is all happening b/c "bad data" got snuck in the database in the first place.

-- Dean

Hi @fabrice-mejean ,

Oh I see; that's basically just an alternative URL to query, instead of (or in addition to) official public repositories.

For example, the OSS Metadata Provider for npm is https://registry.npmjs.org. A Custom Provider is one with an alternative URL. Maybe a vendor site, or a differente repository that uses the same APIs?

As the docs mentioned, we have no idea why anyone would want to do that. But it's technically possible.

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

Hi @ashleycanham ,

This is a fairly complicated issue behind the scene, and is related to how these packages have multiple casings across different versions.

This is something that should be addressed with PG-3100. After upgrading, you'll want to re-index the feed. If any packages still have incorrect casing, you can re-upload them to ProGet to correct the names.

-- Dean

Hi @power_pille ,

That's strange; I'm wondering if there's some kind of collation problem on your database.

Can you run this?

SELECT CONVERT (varchar, SERVERPROPERTY('collation')) AS 'Server', collation_name  as 'Database' FROM sys.databases WHERE name = 'ProGet';

What are the collation you're seeing?

ProGet must be SQL_Latin1_General_CP1_CI_AS

-- Dean

Hi @dev_7037 ,

This is not possible and we have no plans to add support for this.

Some users have reportedly used reverse proxies and page/URL-rewriting, but it's a headache and usually causes problems. Best to use a different host name and change URLs accessed by clients.

-- Dean

Hi @Anthony ,

The API Access Logs are intended for troubleshooting purposes, not auditing/access monitoring. So I'm afraid there's no way to increase it.

-- Dean

Hi @power_pille ,

I haven't seen that error before, but I suspect it could occur during a race condition while simultaneously trying to access newly-accessed packages. During an intense package restore, the window for the race condition would widen.

It should go away however. If you can look at the error messages logged in ProGet, it'll help give an idea:

Violation of UNIQUE KEY constraint 'UQ__PackageNameIds'. Cannot insert duplicate key in object 'dbo.PackageNameIds'. The duplicate key value is (nuget, <NULL>, NuGet.CommandLine).

In this case, the package is NuGet.CommandLine -- so hopefully you wouldn't see that again. Let us know if that's not the case, and if you repeadly see the same package.

-- Dean

Hi @yaakov-smith_7984 ,

We do not have this API, but it's on our roadmap for Q4; it's going to be a set of command like pgutil users or something to that effect.

-- Dean

@tames_0545 thanks for letting us know, we'll get this fixed right away via PG-3065 in the next maintenance release