Was FindPackageById name matching changed in Nexus 3.93?

Sonatype Nexus Repository
1

Since upgrading from Nexus 3.92 to 3.93 we are seeing an issue with NuGet repositories.

If seems like the FindPackageById used to do an extra match but maybe now does a starts with match
that is returning other packages and that is messing up the

We are using dotnet-outdated-tool to show packages that need to be updated. Until the update
to nexus 3.93 this was working fine. Now I am seeing reports of out of date packages but the “new”
version is in another package - one that has the same base name but has other characters. I tried older
versions of the dotnet-outdated-tool to make sure the problem was not in the tool.

Our packages are based on the branch name. For example we might have 3 packages

TestPackage (release branch)
TestPackage-main (main branch)
TestPackage-feature_foo (feature/foo branch)

If our project references TestPackage and we run the tool then it would return updates from
the TestPackage package only. Since 3.92 we are seeing updates from other package names
that start with TestPackage. If they are greater versions than TestPackage it reports that as
needing to update (but it does not).

In our case TestPackage is on version 2.21.5 and TestPackage-main as version 3.0.6. Even though
our project only reference TestPackage we are seeing an update in dotnet-outdated-tool. The update
does not show up in Visual Studio package management.

Looking at the Nexus logs I see then queries being made while runnig the dotnet outdated tool
which I can call using curl.

curl -i “https://nexus.example.com/repository/test/FindPackagesById()?id=‘TestPackage’&semVerLevel=2.0.0”
curl -i “https://nexus.example.com/repository/test/FindPackagesById()?id=‘TestPackage’&semVerLevel=2.0.0&$skip=40”

I am seeing the packages from other branches being sent back.

Is this a change in the 3.93?

2

Hi, Brian,

Looking through our Release Notes and our recently closed tickets, I don’t see anything that exactly matches what you’re seeing.

I’ll continue to look, but in the meantime, let us know: is this NuGet v2 or v3?

3

I believe the match here is accidental, the previous code had performance and memory issues and we made a change to improve it by using the search APIs.

4

I think this is an older V2 API that dotnet-outdated-tool is using but the behavior has changed. I tried with an older dotnet-outdated-tool version to make sure it was not the tool side.

I ran a test with nuget.org and I see the behavior to do a an exact match and not “starts with” match.

This call returns entries where removing the last “e” in the id returns an empty list.
curl “https://www.nuget.org/api/v2/FindPackagesById()?id=‘Serilog.Sinks.Console’&semVerLevel=2.0.0”

If I run the same test against Nexus using a known existing package (e.g. TestPackage) that returns packages and then try ‘TestPackag’ Nexus still returns entries and I don’t think it should.

We use this tool for package updates a lot and this change in behavior is returning updates for packages that don’t exist because the other packages have the same base name but newer versions.

5

Now I am getting build errors because of this. On my CI server it says it tried to download TestPackage 1.24.3 and instead got TestPackageBase 1.24.3 (which is completely different package).

I tried to revert to Nexus 3.92.3 but it gets startup errors. I assume something got updated in the database or elsewhere and it can’t rollback. I am still looking to try to figure out the cause.

6

I was able to revert to Nexus 3.92.3 by using a database backup from before the upgrade. After some cache cleanup this resolved the build errors on my CI machine.

I will stay on 3.92.3 until this issue is resolved.

7

Hi, Brian. We’re tracking this internally and I’ll update you as I learn more.