The queue was causing methods and subscriptions to run out of order. I pushed a commit that also queues subscriptions to maintain the order.

Meteor.isAsyncCall is broken. I'm not sure what the purpose of the function is, and how it should behave with the queue.

1. Currently it is only true when using Meteor.callAsync. Should it also be true when using Meteor.applyAsync?
2. Currently it is true from when calling Meteor.callAsync until the server result is returned. With the queue, do you expect it to behave the same (return true if there is at least one async call in the queue or waiting for the server result), or should it only be true while the stub is running or when waiting for the server result?

The tests copied over from the zodern:fix-async-stubs package won't pass until #12888 is fixed. I gave up on supporting Meteor 3 when I found that bug, so I'm not sure if there are any other Meteor 3 specific issues with the code.

It seems all of the tests are now passing except for the ones copied from zodern:fix-async-stubs (which requires #12888 to be fixed first).

Hey @zodern! The idea for Meteor.callAsync is to behave what we would expect for an async version of Meteor.call, meaning that if we can have a stub we will return it. Otherwise, we will unwrap it for our end user. If the developer wants to use directly the server result, he can get the server result by awaiting result.server. What @radekmie has proposed alongside me and @denihs was this behavior below:

const something = Meteor.callAsync(...);

const resultFromStub = await something; // Or `resultFromServer`, if there's no stub.
const resultFromServer = await something.server;

I think we should follow this API design, developers migrating to meteor3 and people starting now can follow it easily.

I would like to hear your thoughts @zodern

I had proposed a similar api here with some differences.

I think Meteor.callAsync needs to always return the promise for the server (with a way to get the stub result when needed):

1. This is backwards compatible with Meteor 2
2. At least in the app's I've seen the code for or worked on, the server result is almost always used, and it is rare for the stub result to be used, even for methods that have a stub
3. Generally stubs are run for their side effects instead of their result

Currently, Meteor.call is a simple api for when code wants the server result, and Meteor.apply is a more complicated api that can also be used to get the stub result. It would be nice if Meteor.callAsync allows getting the stub result but it shouldn't replace its purpose of providing a simple way to get the server result.

const promise = Meteor.callAsync(...);

const resultFromStub = await promise.stubPromise;
const resultFromServer = await promise;

// backwards compatible with existing code:
const resultFromServer = await Meteor.callAsync(...);

In your proposal @zodern, if the stubPromise is undefined, we would return it or return the server result?

In your proposal @zodern, if the stubPromise is undefined, we would return it or return the server result?

Meteor.callAsync would always return the server promise, with an additional property for the stub promise. I would assume the stub promise would always be defined (and resolve to undefined for methods without a stub) but it doesn't have to work that way.

I have drafted(still working on missing tests) your proposal @zodern(server-first), I got a little bit confused while dealing with the flags for the stubs-first proposal.