tracel-ai/burn · error
The sequential scheduler step counter overflowed
Error message
The sequential scheduler step counter overflowed
What it means
Overflow guard in `SequentialLrScheduler::step`: the internal step counter (usize) is incremented with `checked_add` on every scheduler step; after ~2^64 steps it would wrap, so the scheduler panics instead of silently corrupting milestone selection.
Source
Thrown at crates/burn-optim/src/lr_scheduler/sequential.rs:110
schedulers: Vec<DynLrScheduler>,
milestones: Vec<usize>,
step: usize,
}
impl SequentialLrScheduler {
fn active_scheduler(&self) -> usize {
self.milestones.partition_point(|&m| self.step >= m)
}
}
impl LrScheduler for SequentialLrScheduler {
fn step(&mut self) -> LearningRate {
let index = self.active_scheduler();
let lr = self.schedulers[index].step();
self.step = self
.step
.checked_add(1)
.expect("The sequential scheduler step counter overflowed");
lr
}
fn to_record(&self) -> LrSchedulerRecord {
let mut record =
LrSchedulerRecord::from_state(&SequentialLrSchedulerState { step: self.step });
for (index, scheduler) in self.schedulers.iter().enumerate() {
record = record.with_record(&index.to_string(), scheduler.to_record());
}
record
}
fn load_record(&mut self, record: LrSchedulerRecord) {
if let Some(state) = record.into_state::<SequentialLrSchedulerState>() {
self.step = state.step;
}
let schedulers = core::mem::take(&mut self.schedulers);View on GitHub (pinned to d16f7ba2ed)
Solutions
- Practically unreachable; only occurs with billions of scheduler steps
- Reset the scheduler state via its record if running extremely long trainings
- Reduce milestone/step frequency if step counts are artificially high
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at crates/burn-optim/src/lr_scheduler/sequential.rs:110 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05).
Data as JSON: /api/errors/d2982dee8b977493.
Report an issue: GitHub.