MongoDB access was not done in a way that always guaranteed consistency.
If multiple alterations were performed to a user's application(s) concurrently, it was possible for some of them to get overwritten (thus lost) by others, making MongoDB inconsistent with the reality of the gears on the node. The canonical example was if the same app was scaled up by two separate logins concurrently, one of the gears would not be known to MongoDB.
Distributed locking mechanisms were introduced with the DB schema and model refactor that went into OSE 1.2. Upgrade to OSE 1.2.
User actions should be successfully queued for consistentcy.