How to stop remote.call from firing twice in 2ms?

[a4xrbj1]

@rjdavid

Seems like awaiting findAndModify() can help here

When just looking at these three lines, yes.

But we need the if clause as we only execute a plethora of code when this isn’t a duplicate firing of the remote call.

Now my understanding of the findAndModify is that it’s a Swiss Army knife, with the remove, update or upsert option. Not sure what it delivers back on upsert but it’s anyway just executing the two operations that is in our code anyways, so I see no speed improvement.

[rjdavid]

@a4xrbj1

so I see no speed improvement.

It’s not about speed. It’s about atomicity

[a4xrbj1]

@rjdavid

It’s not about speed. It’s about atomicity

Do you ever sleep, RJ?

[a4xrbj1]

@rjdavid

Just to be sure that we are covering everything, I am not sure how setTimeout matters in that code. Can you explain further?

Let us say that the function will loop 3 times as an example.

If the method call is outside the setTimeout, the method call will be immediately called consecutively 3 times without consideration to the setTimeout.

If the method call is inside the setTimeout, the method call will be immediately called 3 times in succession after 2 minutes.

Sure, it’s called inside the loop (which has the remote call at the end) via:

// delay loop execution
await addDelay();

The function itself is to avoid violating the T&C of the 3rd party service (excessive usage) that we’re working with:

// promise based function to stop for loops or any other execution
const addDelay = async function () {
    // generates a random wait period between min and max milliseconds
    let { minDelay, maxDelay } = Meteor.settings.public;
    return new Promise((resolve) => setTimeout(resolve, Math.floor(Math.random() * (maxDelay - minDelay + 1) + minDelay)));
};

@rjdavid

Can you enlighten me how the setTimeout affects this discussion?

Hope the code posted helps to enlighten

[marklynch]

Was it the same user in both cases or different? Can you see the browser they were using and see if there’s any clue in that? I’m wondering if there’s some buggy promise implementation out there?

[a4xrbj1]

@marklynch

Was it the same user in both cases or different? Can you see the browser they were using and see if there’s any clue in that?

Same user (for each block), one being myself with the latest Google Chrome running on my Mac Mini

That also means running it on a crappy connection like this (kids watching videos are taking a lot of our 1 Gb bandwidth)

[robfallows]

@a4xrbj1

const remotePromise = (...args) => new Promise((resolve, reject) => {
    remote.call(...args, (err, res) => {
        if (err) {
            return reject(err);
        }
        return resolve(res);
    });
});

Why are you doing return reject()/resolve()?

This code should be for example:

const remotePromise = (...args) => new Promise((resolve, reject) => {
    remote.call(...args, (err, res) => {
        if (err !== null) {
            reject(err);
        } else {
            resolve(res);
        }
    });
});

[marklynch]

Well that rules that out

[a4xrbj1]

@robfallows

Why are you doing return reject()/resolve() ?

Not my code. @mexin - you want to answer that?

[satya]

Perhaps you call this code via a method on the client?

If yes, you probably need to scope parts of it with Meteor.isServer or the method simulation will run and call remote.call and once that passes (can happen within 2ms) the ‘actual call’ will run, resulting in the 2 sequential calls that you experience.

[a4xrbj1]

Hi Satya, we do have separate servers for frontend and backend. The main reason is to scale them independently, as the frontend server can take a lot more users than backend (our app is very compute heavy).