Without step_size, StepLR raises 'missing 1 required positional argument',
which is Python-level phrasing that does not tell a config author the value
belongs under lr_scheduler_params. Raise with the config path instead.
Deliberately an error rather than a default: step_size determines the shape
of the entire lr curve, so a guessed value would train to completion and
quietly produce a worse result with no signal anything was wrong.
Same defect as the step branch, opposite direction: the branch used an
unguarded del kwargs['total_iters'], so get_lr_scheduler raised
KeyError: 'total_iters' whenever it was called without the trainer's
injection. Switch to the same pop() used elsewhere so every branch is
safe both with and without the key.
BaseSDTrainProcess always injects lr_scheduler_params['total_iters'], but
StepLR takes only step_size/gamma/last_epoch, so any config using
lr_scheduler: "step" dies with:
TypeError: StepLR.__init__() got an unexpected keyword argument 'total_iters'
Every other branch already copes -- cosine remaps it to T_max,
cosine_with_restarts to T_0, constant_with_warmup deletes it, and
ConstantLR/LinearLR accept it natively. Only the step branch forwards it
untouched. Step decay is fully defined by step_size/gamma and has no notion
of run length, so discarding it is the correct handling.
Rasaboun
martintomov
Jaret Burkett