Skip to content

[BUG]ProductLink ID conflict during Publish after upgrading from v4 to v7 #852

Open

Description

@Asquadia

Release version

APIM v7.0.0

Describe the bug

We are currently migrating our APIM DevOps process from v4 (specifically version [Insert Exact Version]) to v7.

In our existing environment (deployed originally using v4), we have several Groups linked to Products. In the v4 repository structure, these links were handled without explicit IDs in the configuration files.

When using the v7 Extractor on our Development environment, the tool now captures the productLink ID and stores it in the repository.

When we run the v7 Publisher to deploy these changes to higher environments (Test/Prod), the deployment fails.

The error indicates that a productLink already exists on the target environment but has a different Resource ID than the one captured from Dev and stored in the repo.

In v4: The extracted files did not contain a specific productLink ID. Deployment worked seamlessly across environments as it likely matched by name/relation rather than a specific GUID.

In v7: The productLink ID is hardcoded in the extracted JSON/YAML. If the target environment already has that link established with a different ID, the Publisher fails.

Is this change in behavior (hardcoding the productLink ID during extraction) an intended feature or a bug?

Is there a recommended workflow to resolve this conflict during a migration? Should these IDs be tokenized, or is there a way to make the Publisher ignore the ID and match by Product/Group name instead?

Expected behavior

The Publisher should be able to synchronize Product-to-Group links across different environments regardless of the internal Resource ID (GUID).

Since these links represent a relationship between two named entities (a specific Product and a specific Group), the tool should ideally match them by name/reference or update the existing link.

Upgrading from v4 to v7 should not break existing CI/CD pipelines for resources that were previously deployed without explicit IDs.

Actual behavior

The v7 Extractor captures a specific, hardcoded ID for the productLink resource, when the Publisher attempts to deploy this to a target environment where the link already exists (but was created with a different internal ID), the deployment fails with a conflict error.

Reproduction Steps

  1. Environment Setup: Have two APIM instances (Dev and Prod). Link a Group to a Product in both environments
  2. Extraction: Use the v7 Extractor on the Dev environment.
    *the generated configuration file now contains a specific GUID/ID for the productLink.
  3. Deployment: Run the v7 Publisher using the extracted files from step 2, targeting the Prod environment.
  4. Failure: The Publisher fails during the productLink deployment phase because the link already exists in Prod with a different ID than the one captured from Dev.

Activity

  1. github-actions commented on May 12, 2026

    @github-actions
      Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
      Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.
    
  2. guythetechie commented on May 20, 2026

    @guythetechie
    Contributor

    Asquadia - APIM has two ways of composing resources in the REST API:

    • /products/productA/groups/groupA. This automatically creates a link with a random name.
    • /products/productA/groupLinks/linkName

    v4 used the non-link API. In v7, we standardized on the link API where possible. This helped avoid various bugs and futureproof things. The downside is what you're experiencing: you can't publish if a link already exists with a different name.

    My recommendation would be to manually delete the link in the target APIM instance (in the portal, simply remove the group from the product). The publisher should then succeed if you try again.

    Hope this helps. Please feel free to comment with additional questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions