mypy error: incompatible types in assignment flagged on PR

Not specified by the original author.

TL;DR

mypy is telling you the value's type and the variable's declared type disagree; one of them is wrong. Read both types in the error, fix the incorrect side (the annotation or the value), and re-run mypy. Do not silence it with a bare ignore until you know which side is right.

src/app.py:14: error: Incompatible types in assignment (expression has type "int", variable has type "str")  [assignment]

1. Reproduce locally: mypy src/app.py. Expected: the same incompatible-types error with both types named.
2. Read the two types. If the annotation is wrong (the variable really holds the new type), update the annotation:

count: int = int(raw_value)

Expected: mypy passes.

3. If the value is wrong (the variable must stay the declared type), convert or fix the value at the source instead of changing the annotation.
4. If both types are legitimately possible, widen the annotation: value: int | str. Expected: mypy passes.
5. Re-run the exact gate command from CI. Expected: Success: no issues found.

Use this when

• The PR type-check gate fails on incompatible-types-in-assignment
• A refactor changed what a variable holds but not its annotation
• You need to decide whether the annotation or the value is wrong

Not for this skill when

• The error is a different mypy code (arg-type, return-value); each has its own fix
• mypy passes locally but fails in CI; check mypy version and config parity first
• You are tempted to add a type ignore; fix the types instead unless it is a known stub gap

Variant phrasings

• "mypy incompatible types in assignment how to fix"
• "expression has type variable has type mypy"
• "mypy assignment error PR"

Why it happens

mypy pins a variable's type at first assignment (or at the annotation). Later assigning a different type breaks the contract, usually because a refactor changed the value's type while the annotation stayed stale, or a function started returning something new.

Edge cases

• An unannotated x = [] forces mypy to infer from later usage; annotate empty collections explicitly (x: list[int] = []) so later assignments do not clash.
• Third-party stubs can lie about types; if the value is right and the stub is wrong, a targeted ignore with a comment is acceptable.
• Narrowing with isinstance changes the type inside the block only; assigning the narrowed value back out to the wider variable is fine, the reverse is not.

Provenance

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

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

Thread query: mypy error: incompatible types in assignment flagged on PR

TL;DR: mypy is telling you the value's type and the variable's declared type disagree; one of them is wrong. Read both types in the error, fix the incorrect side (the annotation or the value), and re-run mypy. Do not silence it with a bare ignore until you know which side is right.

Not specified by the original author.

TL;DR

TS2322 means the value you assigned does not match the declared type; the error names both types. Diff them, find the property or shape that disagrees, and fix whichever side is wrong: the value or the type declaration. Re-run tsc --noEmit until it is clean.

src/app.ts(14,5): error TS2322: Type 'string' is not assignable to type 'number'.

1. Reproduce: npx tsc --noEmit. Expected: the same TS2322 with file, line, and both types.
2. Read the full error; for object types tsc adds detail like "Property 'id' is missing" or "Types of property 'x' are incompatible". That detail names the exact mismatch.
3. If the value is wrong, fix the value to match the declared type.
4. If the declaration is wrong, update the type to describe the real shape. For optional data use prop?: type; for genuinely multiple shapes use a union.
5. Re-run npx tsc --noEmit. Expected: exit code 0, no output.

Use this when

• The PR gate fails tsc with TS2322
• An assignment, return, or initialization has mismatched types
• You need tsc's nested detail to find which property disagrees

Not for this skill when

• The error is TS2345 (argument versus parameter mismatch at a call site); related but a different location
• tsc passes locally but fails in CI; check the typescript version parity and that CI typechecks the same tsconfig
• The mismatch comes from a wrong .d.ts; fix or override the declaration

Variant phrasings

• "typescript error TS2322 how to fix"
• "type is not assignable to type ts2322"
• "ts2322 property missing in type"

Why it happens

TypeScript checks assignments against declared types structurally. TS2322 fires when the shapes differ: a missing property, a wrong property type, or a primitive mismatch. It usually follows a refactor that changed the value's shape without updating the type, or vice versa.

Edge cases

• With strict null checks, string | undefined mismatches string; handle the undefined case or widen the type.
• Excess property checks only fire on object literals; the same extra property via a variable passes. Both are worth a look.
• Enum versus string mismatches look cryptic; compare the exact literal types tsc prints.

Provenance

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

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

Thread query: tsc error TS2322: type not assignable to parameter of type

TL;DR: TS2322 means the value you assigned does not match the declared type; the error names both types. Diff them, find the property or shape that disagrees, and fix whichever side is wrong: the value or the type declaration. Re-run tsc --noEmit until it is clean.

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.