Hi Alana, This seems to work for what I am trying to accomplish. Thanks! Scott

Thanks for the quick fix. We didn't have that many packages assigned to the licenses in question, so the workaround of disconnecting all packages from a license and then deleting that license did the trick.

Hi @dm-sidelnikov_5266, Glad to hear it! Please let us know if you have any other questions. Thanks, Rich

Thanks, all good now.

Fix verified on 2024.2 version. Thank you.

Great to hear! Thanks for the followup

Did the multi-part API get implemented for universal packages? This is still an issue.

I am one of the developers, which is why I can assure to you that ProGet is not issuing a 503. This is IIS. However, based on the new information you've provided, it's likely happening because of an abrupt Application Pool termination such as a access violation, stackoverflow, etc. In such a situation, it's not possible for ProGet to log anything; the program (AppPool) immediately crashes. Then IIS issues the 503 error. However, IIS should be logging these in the Windows Event log; so if you can look into what it is, then we can try to debug it further. This is an easy scenario for us to set-up, and it's a common error condition, but we cannot reproduce it.

Surfing Pikachu, That was one of the steps I mentioned in my original post. Did not work for this issue. Alana, Already attached Fiddler before original post. Just showed 404's for symbol requests. Downloading the package locally allows the symbols to be found; but using ProGet's symbol server doesn't work.

Hi @j-d-koning_0111, Just wanted to check in if PG-2738 fixed your issue. We have also been working with another customer that has had similar issues. We determined this was related to setting to Map groups to SAML groups setting. If you have this enabled and do not have any groups claims sent, it was causing the error you saw above. This last issue, PG-2745, will be released in the next maintenance release. As a work around, make sure you have your SAML provider configured to send groups claims. Thanks, Rich

I found the issue. User error on my part. This is a small plan that handles this and I had a Legacy plan doing something similar but not using the Promote API. The pipeline was still pointing to that old plan and I just didn't notice the calls going to Proget. Then I was working on the new plan so as far as I knew it wasn't using the filename but in the old plan it was. Changed to the correct plan and the Promotion worked fine. Sorry for wasting your time on this.

Hi @caspacokku_2900, I apologize for the confusion. I meant that running through the test example you provided (looks like that comment has since been deleted) and this new one, I was unable to recreate both the PostgreSQL errors and the "The given key 'version' was not present in the dictionary." error. I'm thinking the dictionary error is related to either the PostgreSQL errors or a hiccup in the network connection where the response was not fully returned, but had a successful response code causing the request to still be cached. What is also confusing is that the cache should refresh the request after 30 minutes. This means if the caching is causing the issue, it should resolve itself within 30 minutes. Also, I see you have set the metadata caching to 100, which cargo hits pretty quickly. I typically set that to 1000 requests in a crates.io connector because cargo is a very chatty client. The main reason I was asking for a reproduction case is that I wanted to rule out an error in parsing the cargo metadata. With this latest test case you provided, I can verify that everything appears to be parsing correctly. I ran this build 30 times back to back with your settings and connector caching enabled (both metadata and crate caching). In between each build, I cleared the local registry cache and ran cargo clean. I was not able to reproduce these errors or cause issues with the connector cache. This leads me to believe that there is an environmental factor that is causing this issue. Can you please check with your IT team to see if there is anything they are seeing (external HTTP request manipulation, network packets dropping, RAM correction errors, etc..) on your server? Thanks, Rich

Thanks. That of course fixed it.

That's great news ! Thank you for following up :)

Thanks, Tod. That works. I appreciate it!

That worked! Definitely a big work around. We additionally had to set the AppPool for the new site to Classic and disable Forms Auth in the bindings.

Hi @w-repinski_1472, We currently do not have any mechanism for alerting the user when an extension update is available. Our guidance around this is to check extensions for updates after a product is upgraded or when instructed by support. In this case, it was my fault for not alerting you to upgrade the extension to fix this issue. I'm sorry for that and I will make sure this does not happen again. Also, many extensions are included in the install package. These extensions are updated automatically when the product is upgraded. So this won't be a problem with most extensions, it just so happens that the clair extension is not an included one. Please let me know if you have any other questions for us. Thanks, Rich

Hi, DOH! Yes, thanks, that's it. I'm blaming the person that wrote the original script I copied :-) Thanks again for your help. David

Hi @arozanski_1087, I just wanted to let you know that we just released a new version of pgscan, 1.4.2. Going forward it will automatically scan npm packages anytime it is scanning for NuGet packages using a .NET solution or project, there will not be any new parameter needed to enable the search. We are still working on adding yarn support, but that one will take us a bit of time to add. We will update you when that one is ready to be used. Thanks, Rich

Many thanks for that proposal, Steve! The warning label in conjunction with dumping of the package cache sounds like it is worth exploring. I shall discuss it with my security and governance collaborators :-)