Type instantiation is excessively deep and possibly infinite.
I feel like a complete noob - I’m sorry. I’m in a migration from supabase, which I used with zod, to convex. And I now often times run into this TS error. Which right now I don’t know to fix because I don’t understand what’s the actual problem. Claude is simply removing all types says it’s any and calls it a day which of cause is bad.
Also interesting sometimes the error is there but then disappears by itself. So can I fine tune my linting for this?
12 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
yep my entire convex folder just lit up with errors
crazy
this is horrible dev experience
even if i explictely type the response
whats weird is that it initially is able to detect the types and it then crashes out
like this for example
the bottom variable is able to resolve its type. but the same func call at top cant
exact same func call
You can't return
requisitionInDb from a convex function because it's the return type of another convex function, which creates the infinite type loop. More here: https://docs.convex.dev/functions/actions#dealing-with-circular-type-inferenceActions | Convex Developer Hub
Call third-party services and external APIs from Convex
You need to type the enclosing function in a way that does not rely on type inference through the
ctx.run* call. Which means something like const requisitionInDb: Doc<'requisitions'> = await ctx.runQuery(...) won't work, as Doc and friends still rely on Convex generated types.
I usually try to slim down the return value if possible to simplify these cases. So, for example, if you don't actually need the whole requisitionInDb object, but maybe just a few props, just type those props explicitly inline and return those. But if you need the whole object the solution looks similar either way.
@Drips where you at on this? First step is to look for all instances of ctx.run in your convex code. The source of that type error is generally going to be one of these. Do you have a lot of them?Is 131 a lot ?😁
lol maybe - possibly a sign of an anti-pattern unless your project is really big or does a lot with external services
I'd look at changes since the last time your code type checked properly to bring down the scope
Project is really big and also uses external services. 😁
As I’m refactoring from supabase to convex it’s kinda never “worked” I’m still in transition.
Migration from supabase to convex is hell, I saw they write some blog post recently. You might want to take a look at that.
I thought I did read that article but did not saw something about my problem. The fun part is.
In my ide it’s an error in my local vercel build it’s an error but when I push to vercel it’s not a error 🫠
since I started vibecoding i also have a lot of these errors