IsAbsoluteLatestVersion is false for all versions in some packages

[BenLubar]

For example, here's the WindowsCompatibility package (which currently has only one version):

https://www.powershellgallery.com/api/v2/FindPackagesById()?$filter=IsAbsoluteLatestVersion&id=%27WindowsCompatibility%27&semVerLevel=2.0.0

As you can see, the API reports the latest version as not being the latest version:

[jrasch]

I would like to add that this is affecting our ProGet product, which sends the semVerLevel query string argument as per the NuGet server spec.

ProGet relies on the IsLatestVersion property being set because it is used by the UI to determine the necessary redirect when an explicit version is not supplied while browsing a feed, but more importantly it is used to serve script-related PowerShellGet module commands (e.g. Install-Script) that don't require an explicit version (which is pretty much all of them).

If the &semVerLevel=2.0.0 argument is removed from the example reproduction URL, then the IsLatestVersion element's value is true as expected.

[Liquidmantis]

This has been causing pain for our group. We use ProGet as a proxy server for the PS Gallery so that systems that don't have Internet access can install and update modules. This has been broken for a while now (I believe it corresponded with the powershellgallery.com refresh).

[jrasch]

This appears to be fixed now.

[edyoung]

That is strange, because we have not made a change to address this.

[Liquidmantis]

It hasn't changed for us. I also upgraded Proget from 5.1.10 to 5.1.15 and see the same behavior.

[jrasch]

My mistake, there was another version of that package released so the IsAbsoluteLatestVersion property became true, but IsLatestVersion still does not work when that is used as the filter:

https://www.powershellgallery.com/api/v2/FindPackagesById()?$filter=IsLatestVersion&id=%27WindowsCompatibility%27&semVerLevel=2.0.0

[apxltd]

Hey Sydney Smith (@SydneyhSmith) Edwin Young (@edyoung) --

I think you weren't aware of this, but this particular issue is unfortunately causing some of your big customers a whole lot of pain and lot of lost labor because it's made PowerShellGallery effectively unusable in this "proxy" situation. As a result of this bug, they have to dedicate time to manually recreating and copying packages... and It's impossible for our software (ProGet) to work-around the bug because ultimately the data on your end is bad/unpredictable.

Can you provide us with a channel to escalate this so this gets on your radar, and gives your customers some visibility as to when or if it will be fixed?

We have spent quite a bit of time working with our customers to try to navigate Microsoft Enterprise Support, Microsoft Platform Support, etc, and ultimately we just get (very nicely) bounced with "not our problem, please call this 1800 number instead."

Who should we try officially contacting on the inside to get you guys the resources to fix this?

Thanks!

Alex

[edyoung]

I'm the engineering manager for the team which runs the powershell gallery (among other things) so there's no particular need to officially contact anyone else.

To be honest it was not obvious from the issue that this was particularly pressing, so it hasn't received much attention so far.

We will take a look shortly. If you want to provide customers an avenue to add their +1, please point them to this issue or the Powershell gallery support alias cgadmin@microsoft.com

[apxltd]

Thanks so much Ed! I had no idea it was this kind of problem either... I had just gotten pulled into it myself.

[ephos]

To be honest it was not obvious from the issue that this was particularly pressing, so it hasn't received much attention so far.
We will take a look shortly. If you want to provide customers an avenue to add their +1, please point them to this issue or the Powershell gallery support alias cgadmin@microsoft.com

Hi Edwin Young (@edyoung) the recent activity on this thread may stem from an issue we found using ProGet and trying to proxy the PowerShell Gallery. We originally looped in Inedo and they referenced this issue. We had also been in contact with Microsoft. I can provide any more information needed as well if needed. I also +1'd the items above.

[edyoung]

Hi folks! It would help to get a really concrete repro case which captures exactly what the problem is. In my testing https://www.powershellgallery.com/api/v2/FindPackagesById()?$filter=IsLatestVersion&id=%27WindowsCompatibility%27&semVerLevel=2.0.0 returns version 1.0.0 with both IsAbsoluteLatestVersion=true and IsLatestVersion=true, which I believe is correct.

If you can add a few queries which produce the wrong answer, and specifically what is wrong with them, that'll help.

[jrasch]

Here is an example of a package that shows false for IsLatestVersion and IsAbsoluteLatestVersion even though there's only a single version:

https://www.powershellgallery.com/api/v2/FindPackagesById()?$filter=IsLatestVersion&id=%27xDisk%27&semVerLevel=2.0.0

<d:IsLatestVersion m:type="Edm.Boolean">false</d:IsLatestVersion><d:IsAbsoluteLatestVersion m:type="Edm.Boolean">false</d:IsAbsoluteLatestVersion><d:IsPrerelease m:type="Edm.Boolean">false</d:IsPrerelease>

The values for those elements become correct if you drop the &semVerLevel=2.0.0 argument:

https://www.powershellgallery.com/api/v2/FindPackagesById()?$filter=IsLatestVersion&id=%27xDisk%27

<d:IsLatestVersion m:type="Edm.Boolean">true</d:IsLatestVersion><d:IsAbsoluteLatestVersion m:type="Edm.Boolean">true</d:IsAbsoluteLatestVersion><d:IsPrerelease m:type="Edm.Boolean">false</d:IsPrerelease>