Repository navigation
"Type instantiation is excessively deep and possibly infinite", unidentified DO types, attempting to get a clean type from DO RPC Call #3063
Description
In a worker, I commonly use a pattern of calling durable objects from an API worker - when the DOs respond, they either contain a response type (e.g. a serializable object) or a Response type. I use a utility method to split these types similar to a safe assignment operator. Ideally, my code looks like this:
const stub = ctx.DURABLE_OBJECT.get(ctx.DURABLE_OBJECT.idFromName("some-name"));
const [response, fooInfo] = await tryResponse(stub.method("foo"));
if (response) {
return response;
}
// fooInfo is guaranteed and typedNote that the DO in the above example would be something like:
type FooInfo = { something: string }
class MyDOClass extends DurableObject {
async method(something: string): Response | FooInfo {
const r = await fetch("...");
if (!r.ok) {
return r;
}
return { something };
}
}This has a number of issues. In order:
ctx.STUBdoes not appear to return typed stubs when I usewrangler typesin a project with non-local DOs, even if I provide a path to the DO definition directly viascript_name. This feels like a pretty obvious shortcoming, or is the expectation that you'd only use RPC via a single worker that exposes its own DOs? I've worked around this by using a shim for the type, not the end of the world.
export const getStub = <T extends Rpc.DurableObjectBranded>(
ns: DurableObjectNamespace,
id: DurableObjectId
): DurableObjectStub<T> => {
return ns.get(id) as DurableObjectStub<T>;
};- tryResponse is typed similarly to this playground, and has a return type of (roughly)
Awaited<[Response, undefined] | [undefined, T]>whereTisExclude<ReturnType<StubMethod>, Response>.
This should in theory allow me to pass a stub method result to it - and indeed, if I pass something typed as ReturnType<MyDOClass["method"]> to it, the types are correct. However, when I call with tryResponse(stub.method("foo")), I get a Type instantiation is excessively deep and possibly infinite error. I can workaround this as well by using this shim:
type Fn = (...a: any) => any;
export type StubCall<
DOClass extends DurableObject,
K extends keyof DOClass
> = DOClass[K] extends Fn ? ReturnType<DOClass[K]> : never;However, this results in the following code, which is bailing out of a lot of the type system:
const repoStub = getStub<MyDOClass>(DURABLE_OBJECT, DURABLE_OBJECT.idFromName("some-name"));
const [response, fooInfo] = await tryResponse(stub.method("foo") as StubCall<MyDOClass, "method">);
if (response) {
return response;
}
// fooInfo is guaranteed and typedThere is some help here, but it's quite repetitive and ideally the first block of code has enough info to generate the correct types without TS failing due to complexity.
I'll try consolidating to a single project to fix issue #1 (is that really the recommended approach?), but I suspect that I'll still have issue #2 regardless, due to the complex type inference. What are my options here?
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
penalosa commentedon Nov 18, 2024
Thanks for opening this @jesseditson, and for the detailed information. I've added it to our backlog to take a deeper look at 2, to see if we can simplify the RPC TS types to reduce the complexity. In terms of 1, while we can definitely improve the situation (we're thinking of adding a
locationproperty to DO bindings pointing to the path on the filesystem so that among other things we can properly generate types), I think a relatively simple stopgap for now would be adding something along these lines to your worker and using that as yourEnvtype:jesseditson commentedon Nov 18, 2024
Thank you! I'll keep an eye on this issue. I'm not blocked, but it would be very slick for the types to "just work".
WRT the env, that makes sense. I'm assuming this would go in an ambient d.ts file and that the
Envhere is one fromworker-configuration.d.ts- I'm usingnpx wrangler typesto generate these.All together that would make my setup:
worker-configuration.d.tsis generated vianpx wrangler types --env-interface WranglerEnvenv.d.tsextends and augments viainterface WorkerEnv extends Omit<WranglerEnv, "DURABLE_OBJECT">This works but will get a little confusing since various
Envs will be ambiently declared. Admittedly I already am adding some complexity here since I augment allenvin my stack with observability tools, so the type in my case will beExtendedEnv<WorkerEnv>. Not something to address as much as just some case study info.I think I'll still end up just merging the projects since that's what I do in test and it seems to work well. This would then let wrangler fill in the env via
DURABLE_OBJECT: DurableObjectNamespace<import("./index").DoClass>which it knows how to do with local DOs.multiplehats commentedon Jan 16, 2025
@jesseditson did you ever end up improving this? I have a lot of promises showing up like
never. And they're not even complex types, sometimes it's just a simple object.watford-ep commentedon Aug 12, 2025
I'm blocked using
wrangler typesand anything beyond the most simple of definitions.filipfalcon commentedon Apr 15, 2026
Same issue with service bindings in a monorepo.
Rpc.Provider<T>collapses methods toanyfor any non-trivial return type — theRpc.Serializable<T>recursion hits TypeScript's depth limit.Simple returns like
Promise<number>work. Complex ones likePromise<{ status: number; data: T | null; error: boolean }>silently becomeany.We work around it by replacing
Service<T>→InstanceType<T>in the generatedworker-configuration.d.tsvia sed post-processing.