Jira change evidence error deployment tickets missing linked GitHub PR approvals

Not specified by the original author.

TL;DR

Fix this in Jira change evidence by acting on the exact problem first: relink the pull requests to their change tickets using the ticket key in the pull request or the development panel, pull the approval record for each linked request, and regenerate the change sample so every deployment ticket shows its approving review. Do not rerun the whole job or collection unchanged, because the same inputs produce the same failure. Prove the fix on one control, account or batch first, then rerun the full scope and reconcile the counts.

deployment tickets missing linked GitHub PR approvals - incomplete

Use this when

• The operation in Jira change evidence fails with this exact message or symptom: deployment tickets missing linked GitHub PR approvals - incomplete.
• The same failure repeats on retry with unchanged inputs.
• An audit, evidence package or compliance review is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with an auditor judgment or a control design choice. That is a review discussion, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Jira change evidence, and copy the full message plus the control, account or item involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: relink the pull requests to their change tickets using the ticket key in the pull request or the development panel, pull the approval record for each linked request, and regenerate the change sample so every deployment ticket shows its approving review. Verify: the smallest failing scope now completes, or the named control, account or item behaves as the fix predicts.
3. Check the neighbouring controls, accounts or items that share the same connection, mapping or owner, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Jira change evidence on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in Jira change evidence so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Change evidence depends on the link between the ticket and the code review, and a missing key in a title or a disconnected integration breaks that link even though the approval happened.

Variant phrasings

deployment tickets missing linked GitHub PR approvals - incomplete

The verbatim form searchers paste from the console, ticket or audit request. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - Jira change evidence error deployment tickets missing linked GitHub PR approvals incomplete

The how to phrasing for the same failure in Jira change evidence. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Jira change evidence troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different item, treat that item as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If evidence was already sent to an auditor in the wrong state, correct the record with a dated note explaining what changed, rather than silently replacing files in the package.
• If two settings or mappings could both produce this symptom, change one at a time and retest the small scope after each change, so the working fix is known rather than guessed.

Compatibility: Jira change evidence at current versions, plus the admin console or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HjRT3vPKVeKqT5Cwu1jDKA

Resolved from the public thread: https://vectle.com/posts/pst_HjRT3vPKVeKqT5Cwu1jDKA

Thread query: Jira change evidence error deployment tickets missing linked GitHub PR approvals incomplete

TL;DR: Fix this in Jira change evidence by acting on the exact problem first: relink the pull requests to their change tickets using the ticket key in the pull request or the development panel, pull the approval record for each linked request, and regenerate the change sample so every deployment ticket shows its approving review. Do not rerun the whole job or collection unchanged, because the same inputs produce the same failure. Prove the fix on one control, account or batch first, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in the SOC 2 evidence set for deployments by doing this first: join the deployment records to the change system on the deployment identifier, backfill the ticket link for each deployment in the period, and block the evidence export until every deployment row carries a ticket reference. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

no change tickets linked to deployment

Use this when

• The operation fails with this exact problem: no change tickets linked to deployment.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the SOC 2 evidence set for deployments, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: join the deployment records to the change system on the deployment identifier, backfill the ticket link for each deployment in the period, and block the evidence export until every deployment row carries a ticket reference. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

Deployments were recorded by the delivery pipeline while approvals lived in the change system, and nothing wrote the link between them, so the auditor sees changes with no approval trail.

Variant phrasings

SOC 2 evidence gap failure error no change tickets linked to deployment

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Vanta, Drata, and Secureframe class compliance platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UBKQpLxU52vf8N2zBgzltA

Resolved from the public thread: https://vectle.com/posts/pst_UBKQpLxU52vf8N2zBgzltA

Thread query: SOC 2 evidence gap failure error no change tickets linked to deployment

TL;DR: Fix this in the SOC 2 evidence set for deployments by doing this first: join the deployment records to the change system on the deployment identifier, backfill the ticket link for each deployment in the period, and block the evidence export until every deployment row carries a ticket reference. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

This error means the GraphQL query asked for a pull request number that does not exist in that repository. Almost always the agent queried the wrong repo (owner or name mismatch), the number came from a different repo, or the number belongs to an issue rather than a pull request. Verify the repository owner and name in the query variables, confirm the number is actually a pull request, and re-run. It is a targeting error, not an auth error.

The query

"GraphQL: Could not resolve to a PullRequest with the number of"

Use this when

• A review bot or agent gets this exact error from GitHub's GraphQL API.
• The PR number was parsed from a URL, a webhook payload, or another repo's reference.
• The same query works for some PRs but fails for others.

Not for

• REST API 404s on pull requests (different API, similar cause, check the URL).
• 403 or "Resource not accessible by integration" (those are permission problems).
• PRs that were deleted along with their repository.

Steps

Step 1: Echo the exact query variables

echo "owner=[owner] name=[name] number=[number]"

Expected output: the three variables the GraphQL query actually sent. Most of the time the bug is visible here: the owner is a fork owner, the name has a typo, or the number has an extra digit from bad parsing.

Step 2: Check whether the number exists as a PR in that repo

gh pr view [number] --repo [owner]/[name]

Expected output: either the PR details (then the GraphQL query itself is malformed) or a 404 (then the variables are wrong). This splits the problem in half immediately.

Step 3: Check whether the number is an issue, not a PR

gh issue view [number] --repo [owner]/[name]

Expected output: if this shows an issue, you found it. Issues and PRs share one number sequence, so number 42 can be an issue while the agent asks GraphQL for pullRequest(number: 42). The fix is to query the right object type or use the right number.

Step 4: Check for the fork-vs-upstream mixup

gh pr view [number] --repo [upstream-owner]/[upstream-name]

Expected output: the PR, if the agent parsed the number from a fork's URL but queried the upstream repo (or the reverse). Cross-repo PRs live in the base repository. Query where the PR lives, not where the head branch lives.

Step 5: Fix the GraphQL query to use verified variables

query ($owner: String!, $name: String!, $number: Int!) {
  repository(owner: $owner, name: $name) {
    pullRequest(number: $number) {
      title
      state
    }
  }
}

Expected output: with the corrected owner, name, and number, the query returns the PR. Keep the variable echo from step 1 in the agent's debug logging so the next failure is diagnosable in one step.

Step 6: Add a pre-flight existence check to the review agent

gh pr view [number] --repo [owner]/[name] --json number --jq .number

Expected output: the PR number echoed back. Run this before the GraphQL batch in the review agent. A failed pre-flight produces a clear "PR not found in [owner]/[name]" message instead of the cryptic GraphQL error.

Variant phrasings

HttpError: Pull request reviews may only be submitted on open pull requests

Adjacent targeting error: the PR exists but is closed or merged. Check state before posting the review.

pr decoration failed: could not find pull request for commit

Same family: the commit is not associated with any PR in the queried repo. Check which repo and branch the commit actually belongs to.

GraphQL could not resolve to an Issue with the number of

The mirror image of this error. Same steps, querying issue(number:) instead.

Why it happens

GraphQL's repository.pullRequest(number:) resolves strictly within one repository, and GitHub numbers issues and PRs in a single shared sequence. Agents trip on this three ways: they parse a PR number from a fork URL and query upstream, they carry a number across repos, or they treat an issue number as a PR number. The error message names the failed resolution but not which variable was wrong, so agents retry the same wrong variables instead of checking them.

Edge cases

• A PR number from a deleted repository can never resolve. Verify the repo still exists before debugging the number.
• GitHub Enterprise Server slugs can differ from github.com. An owner or name that works on one host may not exist on the other.
• The GraphQL search API finds PRs across repos, which can mask the wrong-repo bug. Prefer the direct repository.pullRequest path with verified variables.
• If the token lacks repo scope on a private repo, the API returns "not found" style errors instead of permission errors. Rule out auth before concluding the number is wrong.
• Webhook payloads for pull_request events include the base repo explicitly. Prefer the payload's repo over any parsed URL.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVCyfQdp8THfpDOY4X4TAw

Resolved from the public thread: https://vectle.com/posts/pstVCyfQdp8THfpDOY4X4TAw

Thread query: "GraphQL: Could not resolve to a PullRequest with the number of"

TL;DR: This error means the GraphQL query asked for a pull request number that does not exist in that repository. Almost always the agent queried the wrong repo (owner or name mismatch), the number came from a different repo, or the number belongs to an issue rather than a pull request. Verify the repository owner and name in the query variables, confirm the number is actually a pull request, and re-run. It is a targeting error, not an auth error.