Some ADO build pipelines show all of the work items in linked items and others only show relevant items. Looking for ideas

I am trying to update linked work items with build statuses in ADO. I created a script that gets linked items from RestApi using the build.id and posts needed updates. Script works fine. My problem is that I discovered that some of the builds have 1-2 linked items in them but other builds have all of the changes and work items listed which is a huge problem in this case.

The workflow in the repo is as follows. Devs create new branches from develop branch, commit changes and do PR back into develop attaching the correct ticket to the PR. Pipelines kick in on merge and after all the stages do a PR into main.

1. Could someone explain why some builds show the correct linked items from PR and some show all of the changes as linked items? I don't believe it is by design.

2. Does anyone have any ideas on how I could get the PR id programmatically from the build itself? If I could get the PR I'd just query the restApi for items linked to PR instead of the build.

3. Any other creative ideas on how to get through this?

Update

Based on the further discussions, we could see from the screenshot that the build was triggered by a PR merge commit. Please note that a PR could bring more than one commits into the target branch, which represented more than one changes in code of the PR target branch rather than a single merge commit. Thus, the WIT linked to those commits were also associated to this build.

There is not a predefined pipeline variable to extract the PR ID of a merge commit. You can split the PR ID from the $(Build.SourceVersionMessage) if the PR is completed with the merge type, whose merge commit message begins with Merged PR <prId>

variables:
    prId: ${{ split(split(variables['Build.SourceVersionMessage'], ':')[0], 'Merged PR ')[1] }}

1. Could someone explain why some builds show the correct linked items from PR and some show all of the changes as linked items?

According to the document to Configure pipelines to support work tracking

What work items are included in automatic linking?

When developing your software, you can link work items when you create a branch, commit, or pull request. Or, you can initiate a branch, commit, or pull request from a work item, automatically linking these objects as described in Drive Git development from a work item.

When automatically linking work items to builds, the following computations are made:

• For a first-time build:
  • Identify all work items linked to the branch, commits, and pull requests associated with the build.
• For subsequent builds:
  • Identify all work items associated with the current commit (C1) being built.
  • Identify all work items associated with the commit (C2) of the last successful build of the same source branch.
  • Identify all work items associated with the commits between C1 and C2 in the commit tree.

If a pipeline has enabled Automatically link work items to builds or releases, it will generate additional link(s) to the related workitem(s) with the link type of Integrated in build or Integrated in release stage. Whether option is enabled doesn't affect the Related work items of the build which can be seen in the build summary page.

2. Does anyone have any ideas on how I could get the PR id programmatically from the build itself?

If a build of your pipeline was triggered by a PR ($(Build.Reason) was PullRequest), you could get the PR id referring to the pre-defined variable value of $(System.PullRequest.PullRequestId).