Azure-functions-host: Beta runtime version javascript functions are broken on Azure
_From @nelak on November 3, 2017 17:34_
Trying to run something as simple as:
module.exports = function (context, req) {
const htmlContent = `<html><body>Hello world</body></html>`
context.res.setHeader('content-type', 'application/xml; charset=utf-8')
context.res.setHeader('content-length', `${Buffer.from(htmlContent).length}`)
context.res.raw(htmlContent);
Results in the following error:
2017-11-03T17:32:15.606 Exception while executing function: Functions.HttpTriggerJS. System.Private.CoreLib: One or more errors occurred. (Worker process with pid 8516 exited with code 1) (Worker process with pid 9788 exited with code 1) (Worker process with pid 8300 exited with code 1). Worker process with pid 8516 exited with code 1.
This is likely related to the same issue reported on the azure-functions-cli repository:
https://github.com/Azure/azure-functions-cli/issues/280
Let me know if you need more information
_Copied from original issue: Azure/Azure-Functions#575_
ahmelsayed
All 17 comments
I can repro this on
Azure Functions Core Tools (2.0.1-beta.21)
Function Runtime Version: 2.0.11370.0
however, that error isn't logged, but the function returns 500
ahmelsayed
on 13 Nov 2017
@christopheranderson I do say above however, that error isn't logged, but the function returns 500 :)
ahmelsayed
on 16 Nov 2017
There is 1 bug and 1 improvement involved here.
I believe you're using the wrong Node.js version, which caused Node.js to not be able to start properly. Please use 8.4.0 and above. https://github.com/Azure/azure-webjobs-sdk-script/issues/2048
The other issue is that "raw" support is broken now. I have a PR out to fix this that will go out in the next v2 release. https://github.com/Azure/azure-webjobs-sdk-script/pull/2064
christopheranderson
on 16 Nov 2017
@christopheranderson This happened using WEBSITE_NODE_DEFAULT_VERSION=8.5.0 in case it helps
nelak
on 16 Nov 2017
Do other functions work, like a simple hello world? They should. raw doesn't work yet.
christopheranderson
on 16 Nov 2017
No, it didn't I started getting errors when updating to runtime: [email protected] my functions used to work before that change. Same code would run locally depending on the runtime it would run < beta.18 and but fail on beta.18.
I created that sample as a way to showcase the issue, but didn't know I would be hitting another bug in the process.
The weird thing is that the OSX build would work but using WSL would error out the same as Azure.
If have some time I can try to build you some other repros tomorrow or during the weekend if it's still not fixed.
nelak
on 16 Nov 2017
@christopheranderson See https://github.com/Azure/azure-functions-cli/issues/280#issuecomment-345128512 for further explanation
nelak
on 17 Nov 2017
raw should never have worked in v2 at all. We didn't have the logic implemented. If it was working before, it would have been a fluke. If you manage to find a previous working version of 2.0 where this worked, I'd be interested to see if I could figure it out, but it's a non-issue since the fix is imminent.
If you have an environment where something simple like:
module.exports = (ctx) => { context.send("hello world"); }
doesn't work, that'd be really helpful.
christopheranderson
on 17 Nov 2017
@christopheranderson It was working on .beta-18, that's how I came across the content-type override issue.
module.exports = (ctx) => { ctx.res.raw("hello world"); }
With regards to the failing scenario, I've been able to finally track it down.
The issue was related to the path of the node worker being referenced as Node but getting installed as node
What made this hard to track was that if you are running against an Azure Queue the message is only printed once at the top, all later messages won't print the reference to the error failing with a System.Private.CoreLib error.
This issue likely made it to Azure and was difficult to track because you don't get the host logs on start, just the function executions.
By the way, does the Cli store executions logs somewhere so one can go back and check for errors?
nelak
on 17 Nov 2017
Ah, that shouldn't affect the latest versions. We made the path lookup case insensitive now.
christopheranderson
on 17 Nov 2017
Yeah, I saw the commits, still the error was pretty confusing because the original error was pulled up by a huge stream of executions generated from an Azure Queue. I know you can easily add logs for the functions execution but this made me realize that I don't know if there are kind of logs for the functions host, which would've been really useful to troubleshoot this scenario.
nelak
on 17 Nov 2017
That's what #2048 will hopefully help improve. Better error messages when there is a host issue.
christopheranderson
on 17 Nov 2017
Excellent, thanks for sharing! 馃挴
nelak
on 17 Nov 2017
If it helps anyone else - I received this error when I had some missing JS files that didn't get deployed and bad JS file paths in the imports.
alohaninja
on 28 Nov 2017
I found out that ESLint leads to exceptions as well. :(
It is a bit annoying by getting all the time the same exception message instead of a detailed information what is happen in the ScriptingHost. The only message I get is like 'Worker process with pid [ID] exited with code 1.'
jfellien
on 6 Dec 2017
The issue was related to the path of the node worker being referenced as Node but getting installed as node
@nelak So what's the solution for that? The error keeps happening for new function apps deployed in Azure and I can't figure out a way to fix it.
anton-bot
on 13 Mar 2018
@catcher-in-the-try The issue I was having at that time was caused by the path lookup being case sensitive
The newer versions I had tried after that worked, last time I used it I was on beta.22 and running without issues.
nelak
on 13 Mar 2018
Related issues
helgemahrt
路
4Comments
christopheranderson
路
4Comments
krillehbg
路
3Comments
paulbatum
路
4Comments
ahmelsayed
路
4Comments
Most helpful comment
That's what #2048 will hopefully help improve. Better error messages when there is a host issue.