Why the decoders are strict¶

Everything the adapter reads, it reads against a closed description of what it expects. Anything outside that description is an error, not something to skip. This is a deliberate rule, and it has a price. This page says why the adapter pays it.

The reason is the same everywhere: an adapter that drops what it does not understand will go on working, and quietly do the wrong thing.

Your configuration¶

The adapter's settings are decoded with these refusals:

Each refusal names the place in the document, for example unknown object member name "Transport", empty value: number 0 at "/ssh/port" is below 1, or duration is not positive: "0s". After decoding, the values are checked within their types: a path must be absolute, output.dir must start with / or $HOME/, no text may hold a control character, environment.pass may not repeat a name, and ssh and transport must agree. Each of those failures names the key as well.

The same rule is in the published JSON Schema, slurm.Schema(), which sets additionalProperties: false at every level. A host can use it to reject a configuration before the adapter ever sees it. The decoder does not depend on the schema having been used.

The ssh options follow the same rule. There is no free-text option, only the closed set the adapter can express, because a free-text option once let StrictHostKeyChecking=no run a command against a host whose key had changed.

Slurm's JSON¶

squeue and scontrol show job are asked for JSON with --json=v0.0.44, which pins the data parser version, and the answer is accepted only if:

• meta.plugin.data_parser says data_parser/v0.0.44;
• every key at every depth is one that parser can write. The set of keys is generated from Slurm's own source, at 25.11.8 and 26.05.4, so a key added at any depth is refused as surely as a top-level one;
• there are no duplicate members and no data after the document;
• the errors array is empty;
• every field the adapter reads is present, is not null, and has the right type. Slurm's {set, infinite, number} triples must have all three members;
• every job has a state.

A reply that fails any of these is an error from the call. It is never a partial observation with some fields left out. Only then can the code that classifies a job rely on every field it reads being there, and never read an unset time as "now" or a missing exit code as "zero".

sacct lines must have exactly the eleven fields the adapter asks for, and compressed node lists such as gpu-[01-03,07] are expanded only in the forms Slurm prints; anything else is refused. An expansion is capped at 65,536 nodes.

The one exception¶

scontrol show config is the whole cluster's configuration, not a document addressed to the adapter, so it cannot be held to a closed set of keys. Preflight reads only the keys it needs. Each must appear exactly once and parse, or preflight fails.

What Slurm and your shell say¶

The same discipline covers messages. The adapter treats a failed command as "Slurm decided and changed nothing" only when its stderr is made of messages from a short list it knows: for sbatch, exactly one line; for a wrapped scontrol call, any number of lines that all carry the same allowed message for the job. An unfamiliar message, an extra line, or a socket timeout is an unknown outcome, and the caller has to find out what happened by looking. A Start whose sbatch printed something unexpected might have created a job.

An ssh failure is "never ran" only when every line of ssh's log is one the adapter recognises as happening before a session exists. See Errors and error mapping.

What it costs¶

Strictness makes the adapter refuse things that might have worked:

• A new Slurm release is refused until the adapter learns it. sbatch --version must report 25.11 or 26.05, and the JSON key set is generated for those two. A release that adds a key to the job JSON fails with an error naming the key, and does not run with the key unread.
• A site that adds a message to a command's output can turn a refusal into an unknown outcome. The outcome is safe, but the caller has to look.
• A configuration typo stops the program where it would otherwise have run.

The adapter takes this on purpose. It makes each of the failures loud and immediate: an error naming the key or the field, at the time you make the change, and not a wrong placement discovered after a run.

Related¶

• Configuration reference
• Tested Slurm versions