Issue listing tags from Gitea as generic registry

[vmsteiner]

Hi

I have setup vscode-docker to connect to my generic registry v2. Under registries I can see my registry, and when browsing it I can view my repositories catalog (so the login / connection must be working). However, when I try to browse the visible repositories catalog for the tags list, the extension just starts loading but never finishes (spinning wheel) until I restart vscode.

Using curl I can get the tags list from the repository, so this makes me think it's a issue with the extension. I also tried pushing an image to the repository / registry, and this also worked. So it really is just having issues browsing the registry at the tags list level.

OS: Windows 10
Docker: Docker Desktop
vscode: 1.89.1
Extension: vscode-docker v1.29.1
Registry: Gitea Packages
I tried both with https and with http (insecure registry). For https I had to use v.1.28 of the extension for it to connect (see issue #4245)

[vmsteiner]

I did some more testing: This works fine in Extension: vscode-docker v1.26.1
At this point, it was still called: "Connect any generic private registry that supports the "Docker V2" api.
They show up, one sees the various tags / images etc. without any issues.

As of extension: vscode-docker 1.27.0 it breaks.

[bwateratmsft]

I haven't looked at the code yet but my hunch is that it's failing to get the tag manifest data.

[bwateratmsft]

I am able to reproduce the issue using Gitea as the package registry. It looks like Gitea is returning the link header with every request even after all records are exhausted, causing the following code to infinitely loop: https://github.com/microsoft/vscode-docker-extensibility/blob/main/packages/vscode-docker-registries/src/clients/RegistryV2/RegistryV2DataProvider.ts#L63-L83

EDIT: No it's not, see #4309 (comment)

[bwateratmsft]

Strictly speaking, this is a violation of the V2 registries API: "The presence of the Link header communicates to the client that the entire result set has not been returned and another request must be issued". That being said, it seems like there are two relatively simple ways to guard against this scenario--first, we could stop looping if the next link is the same as what we just requested, or otherwise, we could stop looping if an empty list is returned.

[bwateratmsft]

Turns out I'm completely wrong. We were stripping out the query parameters from the request URI, causing an infinite loop on any tag listing requests that contained paging. Not sure how we didn't catch this sooner but here we are.

Essentially, we should have done microsoft/vscode-docker-extensibility#214 a different way, i.e. such that the query would be preserved for tags listing as well as repository listing.

[bwateratmsft]

This is now released in Docker extension version 1.29.4.