We are seeing behaviour where cargo build will error because Proget will return 500 Internal Server Error during the download:

$ cargo build
...
error: failed to get `libssh2-sys` as a dependency of package `ssh2 v0.9.5`

Caused by:
  download of li/bs/libssh2-sys failed

Caused by:
  failed to get successful HTTP response from `https://<PROGET_URL>/repository/cargo-proxy/li/bs/libssh2-sys` (<PROGET_IP>), got 500

We have managed to reproduce this issue with a few simple curl commands.

First we download the crate information which returns 200 OK as expected:

$ curl -I https://${PROGET_URL}/repository/cargo-proxy/li/bs/libssh2-sys
HTTP/1.1 200 OK
Server: nginx/1.31.1
Date: Thu, 04 Jun 2026 07:50:47 GMT
Content-Type: text/plain
Content-Length: 115448
Connection: keep-alive
Keep-Alive: timeout=5
Cache-Control: private
Last-Modified: Thu, 04 Jun 2026 07:50:47 GMT
X-ProGet-Version: 26.0.2.16
X-ProGet-Edition: enterprise

Then we download the latest version of the crate which returns 200 OK as expected:

$ curl -I https://${PROGET_URL}/cargo/cargo-proxy/crates/libssh2-sys/0.3.1/download
HTTP/1.1 200 OK
Server: nginx/1.31.1
Date: Thu, 04 Jun 2026 07:51:26 GMT
Content-Type: application/octet-stream
Content-Length: 582851
Connection: keep-alive
Keep-Alive: timeout=5
Cache-Control: private
Last-Modified: Sat, 01 Feb 2025 17:13:17 GMT
X-ProGet-Version: 26.0.2.16
X-ProGet-Edition: enterprise
Content-Disposition: attachment; filename="libssh2-sys-0.3.1.crate"

But then when we try and download the crate information again, it returns 500 Internal Server Error which is not expected.

$ curl -I https://${PROGET_URL}/repository/cargo-proxy/li/bs/libssh2-sys
HTTP/1.1 500 Internal Server Error
Server: nginx/1.31.1
Date: Thu, 04 Jun 2026 07:52:42 GMT
Content-Type: application/json
Content-Length: 1948
Connection: keep-alive
Keep-Alive: timeout=5
Cache-Control: private
Last-Modified: Thu, 04 Jun 2026 07:52:42 GMT

The full error returned is as follows:

$ curl -s https://${PROGET_URL}/repository/cargo-proxy/li/bs/libssh2-sys | jq -r '.errors[0].detail'
The given key was not present in the dictionary.
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at Inedo.ProGet.Feeds.Cargo.CargoMetadata.<.ctor>g__getDependency|3_4(KeyValuePair`2 dependency) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E655333\Src\src\ProGet\Feeds\Cargo\CargoMetadata.cs:line 152
   at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.MoveNext()
   at Inedo.ProGet.WebApplication.FeedEndpoints.Cargo.CargoIndexHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, CargoFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E655333\Src\src\ProGet\WebApplication\FeedEndpoints\Cargo\CargoIndexHandler.cs:line 106
   at Inedo.ProGet.WebApplication.FeedEndpoints.Cargo.CargoIndexHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, CargoFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E655333\Src\src\ProGet\WebApplication\FeedEndpoints\Cargo\CargoIndexHandler.cs:line 89
   at Inedo.ProGet.WebApplication.FeedEndpoints.Cargo.CargoFeedHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, CargoFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E655333\Src\src\ProGet\WebApplication\FeedEndpoints\Cargo\CargoFeedHandler.cs:line 107
   at Inedo.ProGet.WebApplication.FeedEndpoints.CanonicalFeedHandler`1.Inedo.Web.IHttpAsyncHandler.ProcessRequestAsync(AhHttpContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E655333\Src\src\ProGet\WebApplication\FeedEndpoints\CanonicalFeedHandler.cs:line 85

Going into the Cargo feed and clicking "Delete Cached Crate" temporarily fixes the issue but it happens again after the next download.

Thanks for the detailed information; I was able to reproduce the error pretty easily thanks to that.

It seems to be happening when parsing a Dependency entry in the .toml file (missing version), but I can't figure out why since the version appears to be there. It also shouldn't cause this beahvior for this particular error.

In any case, we'll get it fixed via PG-3303 in an upcoming maintenance release. !

Cheers,
Alana