Non-deterministic types inferred

[beerose]

Bug Report

This bug report originates from blitz-js/blitz#2609.
I and other users started seeing any in VS Code where a type should be known. It appears quite randomly (at least for me) and disappeared after e.g. modyfing a file. It's quite non-deterministic, it happens only sometimes, and isn't that easy to reproduce consistently, but it does happen often.

On the following screenshot you can see the type of getProjects function is inferred correctly to be (input: { id?: number }, ctx: Ctx) => Promise<Project>.

However, after making some changes -- e.g. playing with destructuring fields from the second item in useQuery result in projects/projectid.ts#L13-- the type in the tooltip becomes any.

I guess, some types are complex and take more time to compute (hence a VS Code lag?). The variable in question is returned from a pipe function with 11 overloads – can this be the problem?

I tested it with tsc in watch mode and noImplicitAny: true, and didn't see any errors from tsc.
However @ugogo reported errors from tsc, so this may not be limited to language server.

My issues/questions are:

• Do you have any thoughts on what's happening there?
• How to debug these kind of issues, and how to get to know what's happening under the hood?

🔎 Search Terms

any, vscode lag, vscode any, inference problem, blitz, zod, prisma, non-deterministic

🕗 Version & Regression Information

Tested with TypeScript 4.3.3, 4.4.0-dev.20210803

• I was unable to test this on prior versions because Blitz doesn't work with TS versions lower than 4.3, and I'm unable to reproduce this problem in other codebases.

⏯ Playground Link

Unfortunately, the problem doesn't occur in the playground.
I'm attaching the link for completeness' sake: https://tsplay.dev/Nd42YN

💻 Code

// getProject is any
const getProject = resolver.pipe(resolver.zod(GetProject), resolver.authorize(), async ({id}) => {
  return "getProject's result" as const
})

I'm sorry, but I couldn't show the problem in a minimal code snippet. You can see the Playground for all relevant code, but the surest way to reproduce this would be the following:

1. Clone blitz-js/blitz repo: git clone git@github.com:blitz-js/blitz.git and go to blitz directory.
2. Install dependencies: yarn and build Blitz with yarn build or yarn dev.
3. Go to examples/auth directory.
4. Codegen Prisma with yarn blitz prisma migrate dev.
5. Open the following files:
   a. examples/auth/app/projects/queries/getProject.ts
   b. examples/auth/app/pages/projects/[projectId]/edit.tsx
6. Start experimenting with the following line: https://github.com/blitz-js/blitz/blob/canary/examples/auth/app/pages/projects/%5BprojectId%5D/edit.tsx#L13 by destructuring different properties from the object in the second argument of the array. You should start seeing any for project after few tries.

🙁 Actual behavior

Types in VS Code tooltips are sometimes correct and sometimes any in a non-deterministic way.

🙂 Expected behavior

The type of the variable is always the same.

[MartinJohns]

I've had an issue in the past that behaved very similar. It was deterministic and was depending on a combination of which file I saved last and whether I showed a tooltip or not. It resolved itself after an automatic VS Code update. 🤷‍♂️ #40868

[Andarist]

Even though the reported issue here is slightly different I believe they might be related to each other. Initially, I've experienced a very similar problem - inference seemed to be very sensitive to unrelated code changes, applying changes and reverting them back didn't bring the same inference results, things got randomly inferred as any etc.

In the process of creating a minimal repro case, I've found that other issue - it still seemed to be related but was also easier to reproduce and describe so I've focused on that issue in my report.

[gabritto]

@beerose I know it's been a while, but are you still having this issue? are you using newer versions of TypeScript?
I tried playing around with the project using TS 4.7 nightly, and I couldn't get any for the type of project.

[gabritto]

Closing this because I couldn't repro it and haven't received more feedback about it.