Hi @jolaka9284_9458,

Thanks for providing all these details. I was able to pinpoint the reason for the slow down and why it specifically happens on some crates and not others. This is related to some code that we have to determine when to point cargo to pull dependencies from ProGet vs crates.io. Specifically this comes from cargo's API specs for dependencies:

registry — cargo metadata uses a value of null to indicate that the dependency comes from crates.io. The index uses a value of null to indicate that the dependency comes from the same registry as the index. When creating an index entry, a registry other than crates.io should translate a value of null to be https://github.com/rust-lang/crates.io-index and translate a URL that matches the current index to be null.

As you can see, the value specified in the metadata is different than the value the index needs to return. In ProGet, we will return null if the package exists in the feed (including connectors) and https://github.com/rust-lang/crates.io-index if it does not. This is to support the case when ProGet is not used as a mirror and instead for only local crates. Unfortunately the use ProGet as a mirror option is stored only in the client config and is not sent to ProGet.

This is the reason why crates with a lot of dependencies take longer to generate the index than ones that don't and why you'll occasionally get timeouts, but after the retry it works. We have some caching on this to help with performance, but it's not a forever cache.

I'm going to work on some potential improvements for this and will let you know when I have a solution ready. Unfortunately, the only workaround we have for this currently is to use a package approval workflow (like our npm Package Approval blog article).

Thanks,
Rich

Hi @jolaka9284_9458,

Can you please answer the following so I can get an idea of your environment setup?

• What version of ProGet you are running?
• Is your config.toml configured to proxy all cargo requests through ProGet (overriding [source.crates-io])?
• Do you have connector package caching and/or metadata caching enabled?
• Are you using SQL Server or PostgreSQL (the embedded database, InedoDB, etc..)?

I'm not able to test against Artifactory very easily, but testing against crates.io. I'm not seeing a huge difference in speed (~20 seconds in your test case). In my testing, the time varies greatly based on the number of versions a package has and speeds up significantly once the indexes have been cached locally.

My theory is that Artifactory caches these indexes on disk on the server or is not returning the complete dataset (hosted vs local), compared to ProGet where we create the package index each time it's requested and leave the local index caching to cargo. When ProGet generates it's package index, it reaches out to any connectors on the feed and then merges them with the local package versions stored in ProGet.

There are pros and cons to each solution and are only really noticeable when the local cargo cache is cleared. When cargo has a local cache, it will send a If-Modified-Since header in its index request, allowing that index to be skipped if nothing has changed recently.

Is it also possible to get a list of your HTTP requests and timings made during these? I don't need the response body, but the URL Path (host and feed names can be anonymized), response time taken, and response code is all I really need. In ProGet 2025, you can enable HTTP Request Logging to obtain these.

Thanks,
Rich

Hi @coboj59760_1341,

I just pushed a pre-release that includes the fix. Please install ProGet 25.0.17-ci.12 and that should resolve this issue. Please let us know if that resolves your issue.

Thanks,
Rich

Hi @coboj59760_1341,

Thank you very much for all the information on how to recreate the error. In Cargo 1.84.0 (released in January 2025), they changed the default value for default_features from false to true. In the case of the examples you provided, these cargo manifests did specify a value for default_features causing it to change to false once the package is cached in ProGet.

I have created a ticket, PG-3182, to track the fix. This will be released in next weeks release of ProGet. I can also provide a pre-release version of ProGet if you would like. Just let me know!

Thanks,
Rich

Hi @koksime-yap_5909,

Sounds good. The fix will be released on Friday December 19th.

Thanks,
rich

Hi @koksime-yap_5909,

Thank you very much for all the information. I was able to recreate your issue and I'm working on a fix right now. I have created a ticket, PG-3178, to track the fix and should have it resolved shortly. The next release is Friday of next week, but I can provide you with a pre-release to try as soon as the fix is ready if you would like. Please let me know.

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for clarifying that for me. In my testing, the name property always started with repository/<<REPOSITTORY_NAME>>/.... I'm going to dig into this further and should have an update for you tomorrow. One last question, do you have any rules in your reverse-proxy that would be stripping that out of components API?

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for sending this over! It will take me a but to dig through this. Just a couple of quick follow up questions:

1. What is psuedo-group? Is that a repository/registry name?
2. What is subgrouping/groups? It may be helpful to see a screenshot of this example inside of Nexus.

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for following up! Is it possible to share the contents of the JSON your API generates? You can do that by logging into Nexus and entering the following URL in your browser: https://«NEXUS_HOST_AND_PORT»/service/rest/v1/components?repository=«REPOSITORY_NAME»

Please not the Repository Name is your Docker Registry name.

The code does some stuff to strip off the registry name so only the namespace and image name are left. I'm guessing that something is being returned slightly differently. Can you also tell us what version of Nexus you are running? It might help so I can do more testing with that version.

Thanks,
Rich

Hi @koksime-yap_5909,

The separate proxy server port is what is causing the import issue with this. After looking at this further, the main issue is that specified httpPort is overriding the port, even when an https:// URL is being used. I created a ticket, PG-3155, to fix that and add the ability to override the URL used for the Docker API. This fix will be released in ProGet 2025.15. If you are interested, I can get you a pre-release build with the fix in it either later today or tomorrow. Just let me know!

Thanks,
Rich

Hi @felfert,

Thanks for sending that. Since there are no errors right at the beginning, there was no errors in the upgrade process. Most likely restarting the container will resolve the schema issue. I have created a ticket, PG-3154, to add some more output logging in the schema update code to better understand the source of this issue going forward. Please let us know if restarting the container after updating to the 2025.14 does not resolve the schema version mismatch.

Thanks,
Rich

Hi @felfert,

The database schema is updated when the container starts. In the cases where you get a schema mismatch, typically just restarting the container will resolve the issue. This seems to happen every now and again, only in Docker, but we have been unable to reproduce it on our end to fix it. Next time you attempt to update to the new image and see this issue, could you provide us with the output from the start of your container?

Thanks,
Rich

Hi @koksime-yap_5909,

ProGet uses a combination of the Nexus REST API and the Docker API to pull images from Nexus. Just like packages, only local images will be pulled (as in only hosted Nexus Docker registries are supported). The basic process is:

1. Get a list of images using the Nexus components API.
2. Get the Docker API endpoint using the Nexus registries API (this is what you would use in the Docker client)
3. Pull the image (manifest, layers, etc...) using the Nexus Docker API

I'm guessing the error is occurring building the URL to Docker API endpoint. When you say that you are using an external proxy, did you configure the subdomain and port in Nexus to be the subdomain and port of your proxy? Would you also be able to send us the JSON that is returned for the following GET request in the Nexus API?

https://«NEXUS_HOST_AND_PORT»/service/rest/v1/repositories/docker/hosted/«NEXUS_DOCKER_REGISTRY_NAME»

If you can send me the value for the url property and the object for docker property, I can tell you what URL ProGet using to connect to the Docker API. Feel free to obfuscate the host name, subdomain (if configured), and registry name. The JSON will look something like this:

{
  "name": "internal",
  "format": "docker",
  "type": "hosted",
  "url": "http://localhost:8081/repository/docker-example",
  
...

  "docker": {
    "v1Enabled": false,
    "forceBasicAuth": true,
    "httpPort": 8082,
    "httpsPort": 8083,
    "subdomain": "docker-a",
    "pathEnabled": true
  }
}

Thanks,
Rich

Hi @lukas-herzog_4227,

Please try to restart your ProGet container. That will trigger another check for the database upgrade and should fix the issue. If restarting your container does not fix the issue, please let us know.

Thanks,
Rich

Hi @aristo_4359,

It looks like this should be possible with most of the services. I created a ticket, PG-3117, to investigate and add the feature. We will let you know if we find anything that will prevent us from implementing this.

Thanks,
Rich

Hi @aristo_4359,

Thank you for sending that over. I have recreated the issue and created PG-3116 to track the fix. We should have this resolved within the next two maintenance releases of ProGet.

Thanks,
Rich

Hi @aristo_4359,

Is this all rpm packages or just specific versions of a package? Can you share package names and version on the ones that will not delete?

@aristo_4359 said in RPM Bulk Edit Delete does not work:

Also a suggestion, when user delete package the page ideally stay on same page, instead redirecting to main feed on deleting single package and redirecting to first page when deleting using bulk edit

Thanks for the suggestion. The reason we redirect to the feed page after deleting a single package is because we don't know if the package will still exist (has other versions and/or is a remote package) in that feed. Although it is not trivial to check before we redirect, it could be added. I am going to add this to the list to discuss for ProGet 2026.

Thanks,
Rich

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 @caterina,

Good catch! We'll get that fix merged in.

Thanks,
Rich

Hi @windowsteam_8276,

Thanks for bringing this to our attention. We just pushed Otter 2025.1 that includes a fix, Ot-522, for that issue. Please upgrade to that version and let us know if that resolves the issue. Thanks!

Thanks,
Rich