Risk of race condition between initial find and update event on the client?

[GeorgBraun]

Hi there,

I am wondering if there is a risk for a race condition between the initial find and an update event on the client side.

Let's assume the client triggers an initial find() for some data which is handled by the server. The server collects the data and sends it to the client. The client receives the data and then subscribes to update events to get real time updates.

If the data changes right after the server responded to the initial find() and before the client could setup the update listener, is the updated data lost from the client's point of view?

If the answer is "yes", could this be avoided if the client first subscribes to update events and then fires the find()? But then, how can the client know which data is more recent? The one from the update event handler or the one from the find() result?

Many thanks and best regards,
Georg

[daffl]

You'd listen to all the events you want to get updates first whenever your application loads and then update any data accordingly.

[GeorgBraun]

Thanks, David.

Is there a chance or risk that data from a large find() takes more fetching time and arrives later than date from a patched event which happened after find() was called?

What I am worried about is that data from a patched event which should arrive after the find-data actually arrives earlier at the client because it takes less time on the Feathers/NodeJS server?

[daffl]

That depends on how long your queries are taking but I so far have not heard from anybody experiencing that kind of an issue.

[GeorgBraun]

Thanks, David.
If the server would be single-threaded-async-await (like in Python), we could rely on "execute to completion" in a single thread. But as far as I know, NodeJS is using various worker threads which can run truly in parallel on multiple cores.

The reason why we came to the super-unlikely scenario:
We try to understand how to handle real time data updates on related data that is fetched in addition by a Feathers-Resolver and changes shortly after the resolver has copied some data into the find result.
So far, we believe that the client needs to listen for patched events of the related data and overwrite any data, that is delivered as the find() result thru the resolver.

[daffl]

Is the resolver persisting changes to the data? Ideally persistent changes only ever get made by a service. If not, could you wait for data to be up to date? It'd still require listening to updates to keep them up to date but would avoid the unpredictability in this case.

[GeorgBraun]

David,

sorry for the long response time. I had to think about it a couple times. I think now I'm able to express my concerns with more clarity than in my comments above.

Is the resolver persisting changes to the data?

No.

Ideally persistent changes only ever get made by a service.

Right.

The potential race condition that I see is when the resolver is used to fetch related data from one or more other services.
This leads to a situation, where a read from the database, which used to be an atomic SQL action with one or many joins, is devided up into several individual reads with data buffering in between, spread across multiple atomic read operations.

Let me try to sketch an example:

0. Let's assume three services: a message service, a user service and a comments service. The data is related as follows:
   • Every message belongs to one user, implemented by a userID as a foreign key in the message table.
   • Every message may have zero, one or multiple comments. This is implemented in the comments table by a messageID as a foreign key.
   • And of course every comment also belongs to one user, resulting in a userID as a foreign key in the comments table.
1. Client A requests the newest 50 messages, each with the latest 10 comments (if any). Also, the users' first and last names shall be shown.
2. The newest 50 messages are fetched by the message service, which is handled by an SQL select, resulting in an array of messages.
3. The array of messages is passed to the resolver which resolves related data along the relations, with every sub-step being an independent SQL select:
   3.1 It first fetches for every message the corresponding users' first and last names and merges the data into the response data.
   3.2 It then fetches for every message up to 10 of the corresponding comments using the comments service and merges the data into the response data.
   3.3 Finally, it fetches for every comment the corresponding users' first and last names and merges the data into the response data.
4. Now let's assume that while the resolver is awaiting user data in step 3.1, another client, let's say client B, requests a patch of the last name of a particular user. This patch is scheduled after the data fetch in step 3.1. While the patch is awaited, execution control goes back to the resolver.
5. The resolver get's back the unchanged user data from step 3.1 and copies the names into the result data.
6. The resolver then awaits the comments in step 3.2, which allows the event loop to finalize the patch of the user name. This change of data is the broadcasted to all clients that subscribed to the corresponding patch event, maybe even client A - but has no effect to the user data that has been copied to the response data in the resolver at the end of step 3.1
7. The resolver finalizes the remaining steps 3.2 and 3.3 and delivers the result data to Client A.

The problem that I see is that the final response with all related data being resolved and copied is outdated, but arrives later at client A than the patch event.

The potential root cause that I see is the fact that fetching related data should be done in an atomic, non interuptable action, but is spread across multiple actions, opening up the chance for race conditions.

Sorry for the lengthy example. I hope my understanding of Featers and NodeJS is not completely off ...