phenotypic.sdk_.durable_writes_enabled

phenotypic.sdk_.durable_writes_enabled(override: bool | None = None) → bool

Resolve whether the promote fsyncs before renaming.

write() returns once data is in the page cache. Without fsync the kernel may flush the root zarr.json before the chunk data it describes, so a node crash can leave a store that passes valid_staged_store() – metadata parses, shapes agree – while reading fill_value. That is silent wrong data, not a visible failure, and no amount of metadata validation catches it.

The dominant failure mode does not need it: a SLURM timeout kills the process, and the kernel survives and flushes normally. fsync buys protection only against node loss, power failure, and filesystem crash – which is exactly what a cluster job is exposed to and a laptop run is not.

Parameters:

override (bool | None) – --durable-writes / --no-durable-writes, or None to auto-detect.

Returns:

True when the promote should fsync.

Return type:

bool

Note

This checks SLURM_JOB_ID as well as SLURM_CPUS_PER_TASK. resolve_worker_count (_cli_utils.py:65-72) reads only the latter, so this is deliberately broader – not “exactly as” that helper does, which is what the spec’s §3.7 claims. A job that sets SLURM_JOB_ID without a per-task CPU count still gets durable writes.