deepstream does not update rethinkdb document immediately

Question

I guess there is a delay between a record.set(...) call and a document is updated in DB. Note the document is finally updated in DB, but it doesn't happen immediately. I have acceptance tests that covers document updating flow and sometimes it passes as update is detected, sometimes it fails because of the time it checks the DB it has no changes yet. Even when test fails I can check DB manually and see document is updated. Test code uses direct connection to rethinkdb to check the updated document. I wonder if deepstream has actually a delay on record update and how I can tune it. Note that I have no cache like redis enabled for deepstream on test environment. To understand case better have a look at code snippets below.

Consider I have an rpc endpoint like:

   ds.rpc.provide('update-document', function (data, response) {
     var record = ds.record.getRecord(`document/${data.id}`);
     record.whenReady(function () {
       user.set('field','value');
       response.send({ status: 'UPDATED' });
     })
   });

Test code looks like:

   var document = {...}; // document properly created and saved in DB here 
   client.rpc.make('update-document', document, function (error, result) {
     // we hit successfully, so the call ended well
     assert.equal(result.status, 'UPDATED'); 
     rethinkDBService.get(`document/${document.id}`).then(function (documents) {
       assert.equal(documents.length, 1);
       var updatedDocument = documents[0]._d;        
       // problem here: sometimes it has "field" property with 'value'  
       // sometimes it doesn't  
       assert.equal(updatedDocument.field, 'value'); 
       done();
     })
     .catch(console.log)
   })

rethinkDBService is just my wrapper for rethinkdb library that simply gets or inserts data directly to the DB for test purposes.

Answer 1

There isn't a enforced delay on the record being set on the db, but a write to the database is not required to happen before notifying other clients that it has been updated, only to the cache. This helps keep message latency really low.

You can see the line that does that here.

Setting the record and then directly querying it from the database seems to be quite an odd combination, can you tell me more about your use case?