Firebase-tools: Programmatically running deploy rules hangs thread

[brianneisler]

Trying to do something similar to the example in the firebase-tools docs.

var client = require('firebase-tools');
client.deploy.rules({
  firebase: 'myfirebase',
  token: process.env.FIREBASE_TOKEN,
  cwd: '/path/to/project/folder'
}).then(function() {
  console.log('Rules have been deployed!')
}).catch(function(err) {
  // handle error 
});

The rules successfully deploy but the thread seems to hang after running this command. I have ensured that my firebase token is set properly.

Do the tools need to be shutdown in any particular way when being used programmatically?

I'm currently running firebase-tools 2.2.0 and node v5.2.0

[mbleigh]

Because we open a persistent web socket to communicate with our back end,
Node won't automatically exit. You will have to manually call
process.exit() after a successful operation.

On Fri, Dec 18, 2015, 10:11 AM Brian Neisler [email protected]
wrote:

Trying to do something similar to the example in the firebase-tools docs.

var client = require('firebase-tools');
client.deploy.rules({
firebase: 'myfirebase',
token: process.env.FIREBASE_TOKEN,
cwd: '/path/to/project/folder'
}).then(function() {
console.log('Rules have been deployed!')
}).catch(function(err) {
// handle error
});

The rules successfully deploy but the thread seems to hang after running
this command. I have ensured that my firebase token is set properly.

Do the tools need to be shutdown in any particular way when being used
programmatically?

I'm currently running firebase-tools 2.2.0 and node v5.2.0

—
Reply to this email directly or view it on GitHub
https://github.com/firebase/firebase-tools/issues/118.

[brianneisler]

The issue makes sense. Would a call to firebase.goOffline() sever that connection?

For now i've simply broken my deploy script out in to a separate file that is run using child_process.fork(). This feels pretty hacky though.

Also, this might be worth a mention in the example to save others a couple hours of headache.

[ishitatsuyuki]

This really need some documentation, or better fixed.

[mbleigh]

PRs are welcome!

On Wed, Apr 12, 2017, 4:25 AM Tatsuyuki Ishi [e-mail]
wrote:

This really need some documentation, or better fixed.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-tools/issues/118#issuecomment-293548485,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAD_rLBipXpVd7Qwx3MEjQZnYs-S6FKks5rvLSygaJpZM4G4U1O
.

[ishitatsuyuki]

@mbleigh, can you spend some time investigating this? Your business model is too opaque, from the limited things you disclose I can't do anything useful.

I have done some debugging using wtfnode, and this is the current state:

• The closed-source Firebase SDK is shit, you have completely no way to clear the event queue. Nothing is exposed, and I have found no code that references the closure of the socket.
  There's no public issue tracker anyway.
  Note that the CLI is using the 2.x SDK which is much less likely to have feature addition.
• goOffline won't work. There's some timers remaining. I have no idea if 3.x will improve the situation. No documentation, no source code.

[austin43]

@mbleigh Are there other recommendations on this? process.exit() isn't a viable method because if you're running the script inside of another process it will quit the whole thing.

[Memeriaj]

So we've removed almost all of our usages of long running websockets in the CLI (in favor of more direct REST requests). So recent versions of the CLI exit normally on its own when using it progammatically. If this is not the case please open another issue for the specific command (I believe that all of the deploys should be fine, but I suppose there could be some other lingering usages that I was unaware of).