When emulators don't launch the return code should always be non-zero

[akauppi]

This has been mentioned in some other issues (did not find them..), but still remains at least for this one case.

Expected behavior

Whenever there is an error in launching Emulators that causes them to not launch, the firebase emulators:start command should return with a non-zero return code.

This is normal Unix tool behaviour.

Actual

With certain errors, firebase emulators:start prints an error message but return with a zero return code.

The example is from Docker Compose. If I map things wrong, firestore-debug.log is a directory, instead of a file. This confuses the emulators to:

Step #2: emul               | Launching Docker... 🐳
Step #2: emul               | i  emulators: Starting emulators: functions, firestore, database
Step #2: emul               | ✔  functions: Using node@16 from host.
Step #2: emul               | i  firestore: Firestore Emulator logging to firestore-debug.log
Step #2: emul               | 
Step #2: emul               | Error: An unexpected error has occurred.
Step #2: emul exited with code 0

Note the "exited with code 0".

[REQUIRED] Environment info

• firebase-tools 11.2.1
• Platform: Cloud Build

[REQUIRED] Test case

• Have an otherwise working Firebase Emulators project
• Create a folder firebase-debug.log
• Launch the emulators

At exit, echo $? to see the return code.

[REQUIRED] Expected behavior

If the emulators don't start, firebase should return with non-zero code.

[REQUIRED] Steps to reproduce

see Test case

[REQUIRED] Actual behavior

At least in the above case, it returns with 0.

I wish you have the time to look through the code for any such cases.

[google-oss-bot]

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

[akauppi]

Trying to please the bot. Someone might teach me what's the difference between "test case" and "steps to reproduce", though.

@google-oss-bot ok now? :)

[bkendall]

Hmmmm.... I'm learning more about using uncaughtException, uncaughtExceptionMonitor, and what processes are used to exit our CLI. I may be able to take a look into this (but changing the error handling behavior across a wide surface area is... tricky, at best)

[akauppi]

@bkendall I can relate.

I can totally live with this behaviour - have seen it now for years - but as you likely agree, for the long term success of Firebase it's likely good to have a look.

[akauppi]

One case I faced today:

Step #1: Attaching to emul
Step #1: emul               | Launching Docker... 🐳
Step #1: emul               |
Step #1: emul               | Error: Not in a Firebase app directory (could not locate firebase.json)
Step #1: emul               | 
Step #1: emul               | Error: An unexpected error has occurred.
Step #1: emul exited with code 0
Finished Step #1
Starting Step #2

This is with firebase-tools 11.14.4, but lacking a firebase.json file.

The CI execution carries on, although based on the console output the launch of the emulators definitely failed.