tfx extension publish - fails to detect existing extension

[isberg]

After having sidestepped this issue for two days or so and publishing through the web gui I decided to have another go at publishing an extension from the command line. But the best I can get is:

tfx extension publish --token xxx --rev-version
TFS Cross Platform Command Line Interface v0.3.37
Copyright Microsoft Corporation
Checking if this extension is already published
It isn't, create a new extension.
Failed Request: Conflict(409) - The extension already exists.

I am pretty sure that the extension cannot both be published and not. I am also using --rev-version option and it is creating new .vsix files that I can publish from gui.

I am using visual studio online and it does not seem to help to:

• use v0.3.37 instead of v0.3.30 from npm
• create a new extension
• fiddle around with the authentication token
• try to provide a service-url

Would be grateful for any suggestion how to get past or diagnose this.

[willsmythe]

99% of the time, this message means the identity associated with the PAT does not have access to the extension that has already been published to the Marketplace(which is why the message says "It isn't [published yet"]). This can happen if you sign in and publish the extension under one VSTS identity, but then create and try to use a PAT associated to a different VSTS identity

I think we should improve the message here to call this out better since this isn't obvious today.

[masters3d]

Semi related issue: https://github.com/Microsoft/vsts-extension-build-release-tasks/issues/55#issuecomment-350104796

[masters3d]

Checking if this extension is already published
It isn't, create a new extension.

This seems to appear in other errors too, is kind of confusing when there is an extension already published.

[xximjasonxx]

Getting this error when trying to publish - anyway to confirm the VSTS identity theory. Everything seems to check out - Ive given my PAT full access to accessible organizations. Fresh out of ideas at the moment.

[xximjasonxx]

I figured this out. My Microsoft Identity was a complete mess and I had to delete a bunch of extraneous directories and "move" my Azure DevOps org to my default tenant

[sheetalsk17]

99% of the time, this message means the identity associated with the PAT does not have access to the extension that has already been published to the Marketplace(which is why the message says "It isn't [published yet"]). This can happen if you sign in and publish the extension under one VSTS identity, but then create and try to use a PAT associated to a different VSTS identity

I think we should improve the message here to call this out better since this isn't obvious today.

Do you have any solution for this issue?

[hansShin]

Are there any updates on this issue? My team is trying to move away from using user PATs directly and are instead using a service account's PAT in our pipelines, but due to this issue, our pipelines fail unless we use the PAT of the user who generated the first PAT.

Fortunately, we can still get the engineer to generate PATs for us on occasion, but this brings up questions of what happens when engineers leave teams. Currently, there don't seem to be any recommendations for dealing with the problem.

[hansShin]

Is the solution maybe to unpublish and republish as a part of the pipeline? Will the unpublish step fail as well for a new identity? Would we run into issues with orgs who are actively using the extension during the unpublish-republish process?

[jessehouwing]

Are there any updates on this issue? My team is trying to move away from using user PATs directly and are instead using a service account's PAT in our pipelines, but due to this issue, our pipelines fail unless we use the PAT of the user who generated the first PAT.

Fortunately, we can still get the engineer to generate PATs for us on occasion, but this brings up questions of what happens when engineers leave teams. Currently, there don't seem to be any recommendations for dealing with the problem.

I've been using the new Workload Identity to publish extensions. I've documented the process in a blogpost:

https://jessehouwing.net/publish-azure-devops-extensions-using-workload-identity-oidc/

[jessehouwing]

Is the solution maybe to unpublish and republish as a part of the pipeline? Will the unpublish step fail as well for a new identity? Would we run into issues with orgs who are actively using the extension during the unpublish-republish process?

No this will not fix the issue. The issue is fixed by fixing the users on the Publisher. You can ask vsmarketplace@microsoft.com to fix the issue, I've worked with them in the past to get the correct identity in the publisher settings. It's possible the publisher is linked to a different AAD/EntraID and needs a specific guest account identity.