WEBSITE_NODE_DEFAULT_VERSION not working in Linux
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- azure, linux, node.js, typescript
Research direction
The reported entry point is the HttpTrigger, which logs process.version via context.log. Reproduce the Linux Function App Runtime Version 2.0.12969.0 setup with WEBSITE_NODE_DEFAULT_VERSION set to ~10, then trace how the Node.js runtime is selected. Done means the function reports v10.xx.xx and accepts the shown for-await code.
Written by the indexing model from the issue text.
Description
My WEBSITE_NODE_DEFAULT_VERSION is ~10, but if I check the actual Node version (context.log(process.version);) it prints v8.17.0. Is there another setting that affects the Node.js version?
I was pointed at that, when my app crashed with error message
Worker was unable to load function status: 'SyntaxError: Unexpected reserved word'
Stack: /home/site/wwwroot/common/xxx.js:195
for await (const c of blobServiceClient.listContainers()) {
^^^^^
Which seems to be Node.js version related (for await supported after v10.0.0).
Investigative information
Please provide the following:
- Timestamp: 2020-01-30 16:52:14.006
- Function App name: dummyfunapp
- Function name(s) (as appropriate): HttpTrigger
- Invocation ID: e8f7c2eb-4c0d-4a5e-81e6-cdda996f5768
- Region: West Europe
Repro steps
- Create Function App Runtime Version 2
- Create Function that does
context.log(process.version); - Run Function from Portal
Expected behavior
Output: v10.xx.xx
Actual behavior
Output: v8.17.0
Related information
- I'm developing locally (VS Code) and publish function app via VS Code Tool
- Function App OS: Linux
- Runtime Version: 2.0.12969.0
- Dominant language
- TypeScript
- Stars
- 110
- Forks
- 52
- Avg merge
- 7h 33m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-functions-nodejs-worker
-
Handle valid prerelease Node.js versions without failing worker initializationPossibly taken @TsuyoshiUshio claimed this 52 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
area:nodejs-functions dependencies engineering tests
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Specialization race: double startApp() with stale require cache leaves worker on default v3 model with all functions unloadablePossibly taken @swapnil-nagar claimed this 57 days ago. Open
Difficulty 5/5 Over a week Newbie friendliness 30/100
Azure/azure-functions-nodejs-worker#838 · 1 comment ·
-
c-ares DNS misconfiguration on Windows Consumption causes mongodb+srv:// and dns.resolve*() failuresOpen
Difficulty 4/5 3-5 days Newbie friendliness 64/100
Azure/azure-functions-nodejs-worker#830 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in Azure/azure-functions-nodejs-worker
Similar issues
-
freshness freshness:observed-only
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
thoroc/context-radar#280 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
-
documentation story
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
bug category:billing priority:p3 track:fast
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
LanternOps/breeze#9223 ·
Maintainers usually reply within 1 day