Events called synchronously after write operation

[brentahiti]

• Operating System version: OS X 10.12.6
• Node version: 6.9.1
• Library version: 5.4.3
• Firebase Product: database

Basically, child_added/child_changed events (listened on locally) are called synchronously after .set() or .update() for example.

I'm not sure if it's made by design, but I find this behavior counterintuitive. I would expect code right after a set to be run before any event callback gets called.

'use strict';

const firebase = require('firebase-admin');
const firebaseApp = firebase.initializeApp({
    credential: firebase.credential.cert('path/to/credentials.json'),
    databaseURL: '<app>.firebaseio.com'
});

const ref = firebaseApp.database().ref();


ref.child('test').on('child_changed', (snap) => {
    console.log('child_changed called on', snap.key);
});

const testPush = () => {
    console.log('pushing in test')
    const pushId = ref.child('test').push({ attr: 'initial' }).key;
    console.log('after pushing in test')
    return pushId;
};

const testChange = (id) => {
    console.log('set in', id)
    ref.child('test').child(id).set({ attr: 'changed' });
    console.log('after set in', id)
};

const id = testPush();
testChange(id);

The above code prints

pushing in test
after pushing in test
set in -KxyYoYapMEfNd-i7rvB
child_changed called on -KxyYoYapMEfNd-i7rvB
after set in -KxyYoYapMEfNd-i7rvB

My expectations are

pushing in test
after pushing in test
set in -KxyYoYapMEfNd-i7rvB
after set in -KxyYoYapMEfNd-i7rvB
child_changed called on -KxyYoYapMEfNd-i7rvB

[google-oss-bot]

Hmmm this issue does not seem to follow the issue template. Make sure you provide all the required information.

[hiranya911]

This is by design.

The whole point of an async programming model is there are no guarantees concerning the order of events. The only guarantees you should rely on are the ones documented at https://firebase.google.com/docs/database/admin/retrieve-data#section-event-guarantees

[brentahiti]

@hiranya911 thanks for the answer. I do understand how the async programming model works. However, the nature of write operations by default is asynchronous unless expressed otherwise in documentation. The firebase documentation doesn't mention anything about this curious behavior.

Again, I'm not referring to the order of events, but rather to the fact that .set() and other write operations should get executed at least on the following tick imo.

[hiranya911]

Given the following events:

A: User code calls ref.set()
B: Data is written to the remote database
C: Local events (ref.on()) fired

The SDK guarantees that B and C take place sometime after A. Beyond that no assumptions should be made regarding the order of B and C. B actually does take place on a separate tick from A. A and C might run on the same tick.

[brentahiti]

In which use case would A and C running on the same tick make sense? setImmediate() could be used to run C after A no?

[hiranya911]

That's not relevant. Client code should never rely on the order of events, and different events getting scheduled on the same tick vs multiple ticks. That's all implementation details, and the SDK can handle them in anyway it wishes. The only guarantees provided are:

• B happens after A
• C happens after A

I think the API docs for set() make this clear too:

The effect of the write will be visible immediately, and the corresponding events 
("value", "child_added", etc.) will be triggered. Synchronization of the data 
to the Firebase servers will also be started, and the returned Promise will resolve 
when complete. If provided, the onComplete callback will be called asynchronously 
after synchronization has finished.