denoland/deno · error · Error
Bad cluster.schedulingPolicy: ${schedulingPolicy}
Error message
Bad cluster.schedulingPolicy: ${schedulingPolicy} What it means
cluster.setupPrimary() (alias setupMaster) copies cluster.schedulingPolicy into a local and requires it to be exactly SCHED_NONE or SCHED_RR, the numeric constants exported by the cluster module; anything else throws a plain Error with this message. The default derives from NODE_CLUSTER_SCHED, so an unexpected value usually means code or config assigned a string like "rr" or left the policy undefined.
Source
Thrown at ext/node/polyfills/internal/cluster/primary.ts:117
const settings = {
args: ArrayPrototypeSlice(process.argv, 2),
exec: process.argv[1],
execArgv: process.execArgv,
silent: false,
...cluster.settings,
...options,
};
cluster.settings = settings;
if (setupCalled === true) {
return process.nextTick(setupSettingsNT, settings);
}
setupCalled = true;
schedulingPolicy = cluster.schedulingPolicy;
if (schedulingPolicy !== SCHED_NONE && schedulingPolicy !== SCHED_RR) {
throw new Error(`Bad cluster.schedulingPolicy: ${schedulingPolicy}`);
}
process.nextTick(setupSettingsNT, settings);
};
cluster.setupMaster = cluster.setupPrimary;
function setupSettingsNT(settings: any) {
cluster.emit("setup", settings);
}
function createWorkerProcess(id: number, env: any) {
const workerEnv: any = {
...(process as any).env,
...env,
NODE_UNIQUE_ID: `${id}`,
};
if (schedulingPolicy === SCHED_RR) {
workerEnv.NODE_CLUSTER_SCHED_POLICY = "rr";View on GitHub (pinned to 9ad36f7a2c)
Solutions
- Use the exported constants: cluster.SCHED_RR / cluster.SCHED_NONE
- Validate before setup: if (p !== cluster.SCHED_RR && p !== cluster.SCHED_NONE) throw
- Map config strings to constants in one place: "rr" -> cluster.SCHED_RR, "none" -> cluster.SCHED_NONE
Example fix
// before cluster.schedulingPolicy = process.env.CLUSTER_SCHED; // "rr" -> throws cluster.setupPrimary(); // after const policy = process.env.CLUSTER_SCHED === "none" ? cluster.SCHED_NONE : cluster.SCHED_RR; cluster.schedulingPolicy = policy; cluster.setupPrimary();
Defensive patterns
Strategy: validation
Validate before calling
const policy = cluster.schedulingPolicy;
if (policy !== cluster.SCHED_RR && policy !== cluster.SCHED_NONE) {
throw new Error(`invalid schedulingPolicy: ${policy}`);
}
cluster.setupPrimary(); Type guard
const isValidSchedulingPolicy = (p) => p === cluster.SCHED_RR || p === cluster.SCHED_NONE;
Prevention
- Only assign schedulingPolicy from the module's exported constants
- Map config strings to constants in one parser, never assign raw config
- Validate policy right before setupPrimary so failures point at the config source
When it happens
Trigger: cluster.schedulingPolicy = "rr" followed by setupPrimary(); setupPrimary({ schedulingPolicy: Number(process.env.SCHED) }) where the env var is unset (NaN) or not 1/2.
Common situations: Docs or blog snippets that use string policy names; env-driven config with a typo or missing value; hard-coded numeric constants ported between versions.
Understand the failure class
Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.
Related errors
- ERR_OUT_OF_RANGE
- ERR_TLS_PROTOCOL_VERSION_CONFLICT
- ERR_TLS_INVALID_PROTOCOL_VERSION
- ERR_INVALID_ARG_TYPE
- ${name} must be 'an integer' but was ${value}
AI-assisted analysis of denoland/deno@9ad36f7a2c (2026-08-20).
Data as JSON: /api/errors/069a64a5defe7c09.
Report an issue: GitHub.