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.

[a-type]

Ok, after experimentation, I found that this runtime no-op wrapper cleans up the array type so that it's properly instantiated when using the hcWithTypes methodology:

type RemoveDisposable<T extends Disposable> = T extends infer U & Disposable
	? U
	: never;
function wrapServiceData<T extends Disposable>(data: T): RemoveDisposable<T> {
	return data as unknown as RemoveDisposable<T>;
}

// usage
const data = await ctx.env.SOME_RPC.getThing();
return ctx.json(wrapServiceData(data));

It's a little inconvenient to have to wrap all values passed to ctx.json with this, but it's a start. Perhaps there's some Hono userland magic that can be done to either augment .json to do this, or add a different return helper which performs this type conversion automatically.

This is a sufficient workaround to not warrant internal changes to Hono I think, but I do think it would do well to mention this in the Cloudflare Workers section of the docs!

[github-actions]

This issue has been marked as stale due to inactivity.

[github-actions]

Closing this issue due to inactivity.

[a-type]

For posterity, use the above workaround.

For consideration by Hono maintainers -- adding the RemoveDisposable utility type to the computation of response types in Hono RPC. Or, barring that, documenting this behavior in the Cloudflare Workers integration section. I may file a PR for the latter if I have time.

[yusukebe]

Hi @a-type

Or, barring that, documenting this behavior in the Cloudflare Workers integration section. I may file a PR for the latter if I have time.

Documenting it is good. It would be great if you could create a PR!