Description
When a scheduled train cannot resolve a destination, the three destination instructions call ScheduleRuntime.startCooldown(). The retry interval is always 40 ticks.
On a large network, a failed attempt can traverse a substantial part of the track graph. Trains that fail for the same operational reason (blocked route, temporarily unreachable station, or a station pattern with no reachable match) therefore retry at the same two-second cadence. A server stall or restart can align many runtimes, turning the fixed retry cadence into recurring path-search bursts.
Production symptom
On a 1.21.1 server with about 100 Create trains, periods of unresolved routing coincided with repeated server warnings such as:
Can't keep up! Is the server overloaded? Running 2972ms or 59 ticks behind
This issue does not claim that failed routing is the only source of those stalls. The source-level concern is that the fixed cadence amplifies an existing overload by synchronizing expensive retries.
Proposed behavior
- Exponential retry intervals of 40, 80, 160, and 320 ticks for consecutive failures.
- A deterministic 0-39 tick offset derived from the train UUID to spread different trains across server ticks.
- Reset the failure count immediately after a path is found or the runtime is reset.
- Keep retries bounded; a recovered route is discovered in at most roughly 18 seconds at the maximum interval.
A prepared patch is based on the current mc1.21.1/dev branch and leaves successful navigation behavior unchanged.
Description
When a scheduled train cannot resolve a destination, the three destination instructions call
ScheduleRuntime.startCooldown(). The retry interval is always 40 ticks.On a large network, a failed attempt can traverse a substantial part of the track graph. Trains that fail for the same operational reason (blocked route, temporarily unreachable station, or a station pattern with no reachable match) therefore retry at the same two-second cadence. A server stall or restart can align many runtimes, turning the fixed retry cadence into recurring path-search bursts.
Production symptom
On a 1.21.1 server with about 100 Create trains, periods of unresolved routing coincided with repeated server warnings such as:
This issue does not claim that failed routing is the only source of those stalls. The source-level concern is that the fixed cadence amplifies an existing overload by synchronizing expensive retries.
Proposed behavior
A prepared patch is based on the current
mc1.21.1/devbranch and leaves successful navigation behavior unchanged.