Incorrect client RPC response inference for Cloudflare Workers RPC return types which stub Arrays

[a-type]

What version of Hono are you using?

4.6.15

What runtime/platform is your app running on? (with version if possible)

Cloudflare Workers

What steps can reproduce the bug?

Unfortunately both products use "RPC" naming here, so I'll try to be clear about which is which.

As recommended in Cloudflare Workers RPC docs for Typescript, I am specifying my bindings types using the Service<T> wrapper type to generate proper 'stub' typings which enforce requirements related to chained RPC methods becoming async, for example.

class PublicApiService extends WorkerEntrypoint {
  async getList() {
    return [{ name: 'foo' }, { name: 'bar' }];
  }
}

// in the main API worker --

interface Bindings {
  PUBLIC_STORE: Service<PublicApiService>;
}

const app = new Hono<{ Bindings: Bindings }>()
  .get('/list', async (ctx) => {
    const list = await ctx.env.PUBLIC_STORE.getList();
    return ctx.json(list);
  });

So far I have only encountered issues with return types which were Arrays before wrapping with Service.

What is the expected behavior?

After returning the Array-based data via ctx.json, Hono's RPC typings would correctly infer the response typing as a native Array on the client-side.

What do you see instead?

When using this wrapper type, Hono RPC cannot correctly infer typings of responses for Arrays. Instead, it produces a messy object type on the other end:

type ListResp = {
    [x: number]: {
        name: string;
    };
    ... 40 more ...;
    readonly [Symbol.unscopables]: {
        [x: number]: boolean | undefined;
        length?: boolean | undefined;
        toString?: boolean | undefined;
        toLocaleString?: boolean | undefined;
        pop?: boolean | undefined;
        push?: boolean | undefined;
        concat?: boolean | undefined;
        join?: boolean | undefined;
        reverse?: boolean | undefined;
        shift?: boolean | undefined;
        slice?: boolean | undefined;
        sort?: boolean | undefined;
        splice?: boolean | undefined;
        unshift?: boolean | undefined;
        indexOf?: boolean | undefined;
        lastIndexOf?: boolean | undefined;
        every?: boolean | undefined;
        some?: boolean | undefined;

... and so on

Additional information

Before passing the response to ctx.json, inspecting the type which the Service<T> wrapper has created looks something like this:

const list: {
    name: string;
}[] & Disposable

Disposable is defined in @cloudflare/workers-types as an empty interface, and within standard lib as an object with a key on Symbol.dispose. Since this type is otherwise an Array, I wonder if merely this intersection is undermining Hono RPC's typings, and if that could be accounted for by greedily looking for Array inheritance and forcing the RPC response type to an array in such cases?

Workaround

Removing the Service<T> wrapper on my RPC service bindings resolves the client typing inference problem, but exposes me to mistakes on the server-side regarding Cloudflare's RPC usage. This is an acceptable tradeoff for me a the moment, but it would be nice to have both sides correctly typed.

[yusukebe]

Hi @a-type

I think it's not an actual bug of hono since it's not expected c.json() accepts Disposable. We might be able to support it, but the definition of the type will be more complicated.

[a-type]

Fair, this may be more of a feature request, or possibly could move to a discussion to provide guidance on how to handle this in user-land.

From Cloudflare's perspective I believe the type extension is warranted; their RPC magic necessarily changes the usage of returned objects somewhat and that needs to be reflected in the typings.

As for handling this as a user, perhaps I can try to remove Disposable from the type with a type transformation wrapper, which would be cumbersome but probably acceptable. With how fragile these complex type inferences can be, though, I anticipate that not working as I hope. I'll try to create an isolated reproduction to play with.