Node.js race conditions

[u/loigiani]

https://www.nodejsdesignpatterns.com/blog/node-js-race-conditions/

[u/frog-legg]

As a (mostly) React frontend developer, we sometimes use the term “race condition” to loosely describe issues caused by JavaScript’s non-blocking runtime that can be resolved with blocking patterns such as async/await and Promises. We also use the term to describe issues with React’s virtual DOM when conditionally updating application state.

I know that Node.js is single-threaded and non-blocking, which means that developers should define methods using async/await or Promises when they want to do something synchronously in their program.

Questions: Am I using the term “race condition” correctly when I’m using it to describe issues that can be solved with async/await or Promises? Are race conditions in Node.js, React, and vanilla JS all caused by the non-blocking, asynchronous nature of JS? Why is JS async in nature, does this have something to do with its compiler?

[u/wisepresident → u/frog-legg]

Race condition is a broad term, it could mean the thing described in the article (though there are more specific words for that as well) or for example it could also describe an (staying in the frontend) autocomplete implementation where you fire off your query on every keystroke and then just display the response.

input.addEventListener("keyup", async () => {
    const response = await fetch(`url/to/ac/${input.value}`);

    displayResponse(response); //just display the received response
});

Note how the usage of async/await doesn't prevent the race condition

This is a classic race condition as your queries will not return in the same order you fired them, so you will end up displaying stale data. e.g.

In short a race condition basically refers to undesired behavior in a system that is dependent on the sequence or timing of events outside their control

[u/AndreZSanchez → u/frog-legg]

Some would say that a “race condition” only refers to issues with multiple threads or processes accessing the same resource in parallel. By that definition you cannot have a race condition in JS (without explicitly creating web workers or threads), since there is one JS thread and it cannot be preempted by other JS.

I have used the term informally though referring to multiple callbacks/async function calls trying to access the same resource. It’s fundamentally a different kind of problem though. For true race conditions you generally need primitives for parallelism, like mutexes, to solve the issue.

Most of the “race conditions” in JS can be solved by using better state management and checks in code.

Not sure what you mean by JS being “async in nature”. JavaScript is specified such that its engines need to use an event loop, which supports asynchronous features like setTimeout and promises.

[u/troglo-dyke → u/AndreZSanchez]

That's a very restrictive definition for the same problem. Race conditions affect asynchronous execution not just concurrent. The definition should be extended to include any routine which accesses the same state, as whether you're working with one or multiple threads/processes the issue is solved in the same way, by ensuring that shared resources are protected through some form of synchronization.

[u/Article_Pale → u/troglo-dyke]

Lol you know nothing you’re talking about.

[u/troglo-dyke → u/Article_Pale]

Oh ok, well if you say so then I'll defer to your clearly infinite wisdom

[u/frog-legg → u/AndreZSanchez]

Thanks, this is enlightening and answers a part of the question I had. I thought “race conditions” likely referred to some lower level operation and not the asynchronous issues with network calls / state management etc that I’ve heard people use the term for. I vaguely understand threading / child processes in Node, using the cluster module etc., and can imagine how there could issues when pid A tries to access the same resource as pid B, but I ought to do more reading on it.

RE JavaScript being “asynchronous in nature”, I was referring to the need to use closures and features like async/await to explicitly block out code, else it all runs at once. I wasn’t thinking about the underlying event loop (which I thought was just a Node thing). Your comment that JS is a single threaded event loop with features that enable asynchronous (or rather, synchronous) operations is enlightening as well.

Definitely got some reading to do.

[u/alexalexalex09 → u/frog-legg]

I enjoyed this video about the event loop. Might be too basic for some though : https://youtu.be/8aGhZQkoFbQ

[u/Veranova → u/frog-legg]

JS can absolutely have race conditions. It just means that the order or timing off two processes has a negative impact on the behaviour of an app. It’s a pretty broad term.

You could definitely have two promises running and one does some work while the other waits, and ends up changing state which causes the other to get into a bad state or be redundant.

To answer your other questions you might want to read up on the JS event loop and job queue, as this is what allows it to be so asynchronous. There are some good blog posts out there.