Make entry point failures blocking for v4

[ejizba]

And make this behavior the default starting with Node v20. For Node <v20, we'll provide an app setting FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR to configure this.

There's still an edge case where you get an error before you've registered v4 as the programming model. Not much we can do about that for Node <20 because of #630, though

Fixes Azure/azure-functions-nodejs-library#85
Fixes #697

Updated per offline sync regarding Node 20

[ejizba]

A few updates after going back and forth with Brett on the host team. I was able to get an "end-to-end" scenario tested in Azure and I feel more comfortable with the overall experience now. Two main changes:

1. Log the error using console.log, which will forward the most important worker errors to a user's app insights
2. Don't throw the error during worker init or function environment reload, because the host interprets these failures as "system" errors (aka problem with the worker itself) and gets into a pretty broken state. Instead, throw the error in functionMetadata or functionLoad, which the host interprets as "user" errors (aka a problem with the user's code) and it handles it much better. A few example problems if we throw the error during worker init request:
   1. The portal won't show app keys - it will just load indefinitely
   2. The host will retry loading the worker, and end up sending a bunch of unhelpful errors to the user's app insights like "Error: 14 UNAVAILABLE"
   3. If you try to execute a function in the old model (with the "block" app setting turned on), the host will return a generic 404 error and nothing helpful in the exceptions table in app insights. If we throw the app start error during function load, the host will know to associate that with the execution and surface it in the exceptions table for app insights. (This only applies to the old model, because in that case the host loaded the functions before the app start error occured. In the new model, the app start error occurs before the worker can load the functions.)

[hossam-nasr]

Does it make a difference here logging using console.log vs console.error?

[ejizba]

I thought they were the same, but console.error might result in a more accurate severityLevel in app insights. Let me try it out and get back to you

[ejizba]

Yeah had a better severity level, thanks. Updated