RPC method/`fetch` calling order is not preserved on Durable Objects

[threepointone]

I made a sample repo here https://github.com/threepointone/test-do-ordering, but lemme try to explain.

I have a durable object that looks like this

export class MyDO extends DurableObject {
  testThis = 0;
  someMethod1() {
    console.log("calling someMethod1");
    this.testThis = 1;
  }
  someMethod2() {
    console.log("calling someMethod2");
    this.testThis = 2;
  }
  async fetch(request: Request): Promise<Response> {
    console.log("calling fetch");
    return new Response(this.testThis.toString());
  }
}

In my worker's fetch handler, I call this:

const docId = env.MyDO.idFromName(getRandomRoomName());
const stub = env.MyDO.get(docId);
stub.someMethod1(); // note there's no await here
stub.someMethod2(); // note there's no await here
return stub.fetch(request);

(Note the lack of awaits)

The expected behavior:

• The response is "2"
• order of function calls: someMethod1, someMethod2, fetch

Actual behaviour varies in test, local dev, and production

• with npm test (the vitest environment), I get response "2" and the expected ordering:
  • someMethod1, someMethod2, fetch
• with npm start (local dev with wrangler), I get response "0", and this ordering:
  • fetch, someMethod1, someMethod2
• in production (with npm run deploy), I get "1", and this ordering:
  • someMethod1, fetch, someMethod2

This feels like a bug (@kentonv I remember you telling me it should preserve E ordering)

[kentonv]

Ugh. I guess this is probably because fetch() goes through a very different code path compared to RPC. Might be tricky to fix.

[threepointone]

My usecase for this is calling a .setName(name) method on a DO to set the "name" before any subsequent fetch() calls (because of #2240), but because of the ordering bug I'm having to await the .setName() call which makes every connection to a DO slow :(

[threepointone]

closing this in favour of #6561