Cannot set up `cluster.schedulingPolicy` in ESM

Version

v18.17.1

Platform

Linux xxx 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

cluster

What steps will reproduce the bug?

Run the following code in Node.js:

import * as cluster from 'cluster'

if (cluster.isPrimary) { 
    process.env.NODE_CLUSTER_SCHED_POLICY = 'none'
    console.log(`process.env.NODE_CLUSTER_SCHED_POLICY: ${process.env.NODE_CLUSTER_SCHED_POLICY}`)
    for (let index = 0; index < 2; index++) { 
        cluster.fork()
        setTimeout(() => console.log(`cluster.schedulingPolicy: ${cluster.schedulingPolicy}`), 1000)
    }
} else { 
    setTimeout(() => null, 1000)
}

cluster-error.txt
Attached as cluster-error.txt. You will see that it prints the following:

$ node cluster-error.js 
process.env.NODE_CLUSTER_SCHED_POLICY: 'none'
cluster.schedulingPolicy: 2
cluster.schedulingPolicy: 2

So the env variable NODE_CLUSTER_SCHED_POLICY has no effect, cluster.schedulingPolicy has the value 2 which is the default cluster.SCHED_RR. However running it with the env variable from the console works as expected:

$ NODE_CLUSTER_SCHED_POLICY='none' node cluster-error.js 
process.env.NODE_CLUSTER_SCHED_POLICY: none
cluster.schedulingPolicy: 1
cluster.schedulingPolicy: 1

I cannot set the cluster.schedulingPolicy as per the docs: cluster.schedulingPolicy = cluster.SCHED_NONE since the cluster module is imported:

import * as cluster from 'cluster'
cluster.schedulingPolicy = cluster.SCHED_NONE

so I get a TypeError:

cluster.schedulingPolicy = cluster.SCHED_NONE
                         ^

TypeError: Cannot assign to read only property 'schedulingPolicy' of object '[object Module]'
    at file:///home/alex/projects/loadtest/cluster-error.js:2:26
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

How often does it reproduce? Is there a required condition?

With the attached code it works (as in doesn't work) always.

What is the expected behavior? Why is that the expected behavior?

I expect to see the same output as with the env variable NODE_CLUSTER_SCHED_POLICY='none', i.e. the cluster.schedulingPolicy is set to 1 cluster.SCHED_NONE:

$ node cluster-error.js 
process.env.NODE_CLUSTER_SCHED_POLICY: none
cluster.schedulingPolicy: 1
cluster.schedulingPolicy: 1

(Fake output.)

What do you see instead?

Instead I see cluster.schedulingPolicy has the default value of 2 cluster.SCHED_RR:

$ node cluster-error.js 
process.env.NODE_CLUSTER_SCHED_POLICY: none
cluster.schedulingPolicy: 2
cluster.schedulingPolicy: 2

Additional information

I am the author of the loadtest package and I am converting it to multi-core. I really see a big difference of more than 30% when running the test server in the default round-robin mode and in the none mode I want to set:

• cluster.SCHED_RR: 9600 rps.
• cluster.SCHED_NONE: 12700 rps.

It is true that load on processors is a bit more uneven in none, but that doesn't seem to matter much. I want my lightning fast speed! ⚡

Besides, I think that the documentation should be updated because the recommended way of setting cluster.schedulingPolicy does not work. I would think that the best solution is to have a setting in cluster.settings that can be set with cluster.setupPrimary([settings]). As suggested by @bnoordhuis in this hopeful comment.

Reproduce the ESM example and read lib/internal/cluster/primary.js alongside the cluster.schedulingPolicy, cluster.settings, and cluster.setupPrimary documentation. Trace how the policy is initialized and determine the supported ESM configuration path; done means the reported ESM case is addressed and the documentation accurately describes how to set the scheduling policy.