I believe what you’re seeing is a race condition between the two eve apps. I don’t think it has anything to do with MongoDB or eve at all.
What I think happened is:
- app.v0 tries to update one document
- At the same time, app.v1 tries to update the same document
- Both apps gets the “pre” version of the document, and accordingly set fields
- Both updates are done using something like
replaceOne, where it replaces the whole document
In this scenario, it is a race between v0 and v1. The winner basically has their version of the document. This is why you see only field v0 sometimes, or only field v1 some other times.
j: true has the effect of throttling both apps, meaning:
- app.v0 updates one document, and did so. Field
v0 is now in the document
- app.v1comes after v0’s update, and thus sets
v1. Both fields are now in the document
However, the throttle effect cannot be guaranteed to happen since it was not explicitly designed, so I think occasionally you’ll still see either
v1 like in the non-throttled case.
What I don’t know is whether eve is designed to work like this. That is, multiple eve instances interfacing with a single database instance. In a simplified term, I’m not sure if multiple eve processes are “thread-safe”.
If eve was never designed with these scenario in mind, then you would have to implement an external signalling process so that multiple instances of eve can work together. Alternatively, you might be able to raise an issue in eve github repository.
Of course, this is all assuming that you have parallel eve interfaces running at the same time. If, however, you have a single eve instance interfacing with a single MongoDB instance, and are calling eve’s endpoint from two different REST clients, then we need to dig deeper into what could possibly cause eve to have this race.