Handle valid prerelease Node.js versions without failing worker initialization
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend
Research direction
Start at the WorkerInitRequest handling that parses process.version and inspect the existing semver dependency and version-warning logic. Add coverage for stable supported, unknown major, prerelease, and invalid versions; done means valid prereleases return a warning without failing initialization while invalid versions still throw.
Written by the indexing model from the issue text.
Description
Description
The Node.js worker currently parses process.version by splitting on . and requiring exactly three components. A valid prerelease version such as v26.8.0-alpha.0.0.0 therefore throws during WorkerInitRequest handling and prevents the language worker from starting.
This was exposed by Azure Functions Docker hotfix PR https://dev.azure.com/msazure/One/_git/AAPT-Antares-Functions-Docker/pullrequest/16949790. NodeSource published package 26.8.0-1nodesource1, whose package version appeared stable but whose installed binary reported v26.8.0-alpha.0.0.0.
The upstream package content is the root problem: production images expecting a stable Node.js release must not silently accept a prerelease binary. The worker change proposed here is defense in depth so that version-warning logic does not make the worker unavailable when Node reports a syntactically valid prerelease version.
Proposed behavior
- Parse the version with the existing
semverdependency instead of splitting on.. - Continue deriving the EOL/support check from the parsed major version.
- Return a system warning for valid prerelease versions rather than throwing and failing worker initialization.
- Continue rejecting values that are not valid semantic versions.
Expected tests
- Stable supported versions retain the current behavior.
- Unknown major versions retain the current warning.
v26.8.0-alpha.0.0.0returns a prerelease warning and does not throw.- Invalid version strings still throw a parse error.
Non-goals
This change does not make prerelease Node.js builds acceptable for Azure Functions production images. Image acquisition must independently verify that the installed runtime is the intended stable artifact.
- Dominant language
- TypeScript
- Stars
- 110
- Forks
- 51
- Avg merge
- 8d 8h
- Merged PRs (30d)
- 3
Contributor guide
No contributing guide indexed for this repository
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
-
area:nodejs-functions dependencies engineering tests
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
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*() failures Open
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
-
feature
Difficulty 5/5 Over a week Newbie friendliness 30/100
Azure/azure-functions-nodejs-worker#807 · 2 comments ·
All issues in Azure/azure-functions-nodejs-worker
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100