New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Firebase functions emulator] Introducing a runtime error in the top level scope crashes the emulator. #4613
Comments
And not only emulator. Deployment also crashes:
All I do is initializing the grammy bot: const bot = new Bot(process.env.BOT_TOKEN ?? ''); On deployment the I guess this issue is related to #4538. According to how the fixing PR (#4541) is named, the process of evaluating the source code is called "Node discovery". Interestingly, firebase-tools: 11.0.1 Platform: Windows |
Just checked, the same issue occurs with emulator on Therefore, it seems to be a long-living issue/feature. However I don't tend to treat it as a feature because the documentation specifically suggests to use global variables to reuse objects in future invocations, but the described above issue effectively prevents us from doing so in many cases. Recently I've asked a related question on SO, without answer yet: https://stackoverflow.com/q/72465657/3082178. |
If I understand correctly, the OP is requesting that top-level runtime errors in general, such as @anantakrishna I believe you have a different problem with OP, which is caused by environment variables not being available during discovery and startup. Please see the previous discussion for that: #4614 (comment) . If you have any more questions or context to add, please kindly comment on the thread linked above instead to help all of us stay on track with the issues. |
@yuchenshi yes, after adding my comments here and re-reading all, I realized that my problem is quite different. Excuse me for the mess, I'll switch to that discussion thread. |
Hi I came across similar errors but different case, in my case I'm using typescript, with : firebase-tools: 11.1.0 Here's the debug output:
|
I'm facing this issue too.
|
i have the same problem :/ tried to change many things, downgrading, but nothing helps so far |
We've see a number of concerns here.
I'd love to know what CLI and SDK version you're using. I'd like to see what your function definitions look like (not the business logic, just the |
Thanks for your reply.
|
Window 1:
Window 2:
|
I think you're misunderstanding here. It's not that top level errors should somehow magically be made not broken. It's about not taking down the entire system (really uncleanly as well, as others have mentioned - can't even start it back up without manually killing java processes hogging the ports). All it would require is... well surely nothing but a catch? If it throws, completely ignore it as far as state goes. Spew an error and otherwise pretend it never happened. Every other hot reload software of all kinds have figured out how to do it, maybe due to my limited understanding but I don't get from your explanation why this would differ. Why is the handle gone for good? And if entire env does indeed go toast and is impossible to retain when this happens why not simply reinitialize? Anything that doesn't cause a crash and involves a bunch of time killing processes so you can start the software again... I was trying to quickly write a cloud function in Clojurescript and probably managed to crash everything 40 times while working out the kinks since being used to Figwheel and similar |
To add to @tolgraven's comment: things get worse when running emulators for Auth, Firestore etc as well, with local persistence; because now you don't have a way to clean-shutdown the orphaned Auth/Firestore process, and if you kill it (which you'd have to do anyways, at some point), you'll lose all Firestore data/changes from that session. (Even worse, in some cases, the local persistence store actually ends up corrupted - losing all your local application data, unless you have a previously-saved backup of the persistence directory.) FWIW I'm currently running with As @tolgraven also mentioned, we love the emulator suite (esp. me, who hates needing to have a working/persistent internet connection during dev work); the emulator is our "cloud", and we're just saying that it would be perfect if outage of one service won't bring the whole "cloud" down. |
…4826) Functions Emulator features "hot-reloading" of users source to enable rapid iteration. Today, when users edits their function code that produces runtime error (bound to happen during development), the entire Emulator Suite crashes! This problem gets worse if you are running other emulators like Auth and Firestore since the subprocesses are not cleaned up during the crash. We modify the behavior of the Functions Emulator to simply emit an error log when we can't load function triggers from source code. This means that when an invalid source code for functions is used to start the Emulator, the Emulator will start and report an error instead of crashing immediately. Arguably, the latter is desirable since it makes their mistake more obvious, but I think the overall improvement in DevX is worth the change. Example: ``` $ firebase emulators:start i emulators: Starting emulators: functions ⚠ functions: The following emulators are not running, calls to these services from the Functions emulator will affect production: auth, firestore, database, hosting, pubsub, storage ⚠ Your requested "node" version "14" doesn't match your global version "16". Using node@16 from host. ⚠ ui: Emulator UI unable to start on port 4000, starting on 4001 instead. i ui: Emulator UI logging to ui-debug.log i functions: Watching "/Users/danielylee/google/cf3-vpc/functions" for Cloud Functions... ⬢ functions: Failed to load function definition from source: FirebaseError: Failed to load function definition from source: Failed to generate manifest from function source: ReferenceError: aa is not defined ┌─────────────────────────────────────────────────────────────┐ │ ✔ All emulators ready! It is now safe to connect your app. │ │ i View Emulator UI at http://localhost:4001 │ └─────────────────────────────────────────────────────────────┘ ┌───────────┬────────────────┬─────────────────────────────────┐ │ Emulator │ Host:Port │ View in Emulator UI │ ├───────────┼────────────────┼─────────────────────────────────┤ │ Functions │ localhost:5001 │ http://localhost:4001/functions │ └───────────┴────────────────┴─────────────────────────────────┘ Emulator Hub running at localhost:4400 Other reserved ports: 4500 Issues? Report them at https://github.com/firebase/firebase-tools/issues and attach the *-debug.log files. ✔ functions: Loaded functions definitions from source: vpc. ✔ functions[us-central1-vpc]: http function initialized (http://localhost:5001/danielylee-test-6/us-central1/vpc). i functions: Beginning execution of "vpc" > {"structuredData":true,"severity":"INFO","message":"Hello logs!"} i functions: Finished "vpc" in ~1s ## Make a change to the source code that produces runtime error: ⬢ functions: Failed to load function definition from source: FirebaseError: Failed to load function definition from source: Failed to generate manifest from function source: ReferenceError: aa is not defined ## You can still invoke existing function w/o problems i functions: Beginning execution of "vpc" > {"structuredData":true,"severity":"INFO","message":"Hello logs!"} i functions: Finished "vpc" in ~1s ``` Partially address #4613
Hi folks. I believe the issue raised in the original thread where failure to load the function crashes the parent emulator process is now fixed. I see some tangential concerns, and I hope those issues will be resolved in a new issue - please feel encouraged to create a new issue in this repo. |
While experiencing some other bugs, I noticed that this issue came back. If the functions emulator can't discover the build, it crashes the process, but leaves the firestore emulator and the emulator ui running and blocking the ports. |
Will revisit - thanks @DibyodyutiMondal for the heads up. |
On a separate note, once I close the emulator (with ctrl+c, ctrl+c), the emulators shut down, but the firebase-debug.log contains many many many error logs which say the following:
In fact, it keeps logging it, till the end of the file, roughly 400 times, and I assume it stops because the process exits. I wonder if it's a related issue to this. |
@DibyodyutiMondal Thanks for the followup. Do you mind filing a separate issue for the latter case? |
[REQUIRED] Environment info
firebase-tools: 11.0.1
Platform: Windows
[REQUIRED] Test case
Any javascript runtime error in the global scope (that is, outside the body of any cloud function definition) crashes the emulator.
[REQUIRED] Steps to reproduce
firebase init
in an empty directory.firebase emulators:start --only functions
functions/index.js
file and type something that results in a syntax error. E.g.:Error: Failed to load function definition from source: Failed to generate manifest from function source: ReferenceError: thisIsNotDefined is not defined
[REQUIRED] Expected behavior
The emulator does not crash.
It should issue a warning that it could not load the function code, but it should not crash, thereby also leaving other dangling processes running on the machine.
[REQUIRED] Actual behavior
Here the log of the firebase init command.
And here the command that starts the emulator.
The text was updated successfully, but these errors were encountered: