Thanks for posting this, Simon — this matches exactly what I’m seeing on both Windows and Linux BDS.
This confirms the issue is platform-independent and tied to the 1.21.130 engine change to minecraft:behavior.nearest_attackable_target.attack_interval.
Vanilla mobs like piglins and hoglins never defined attack_interval, so the fallback logic is now broken and emits this log every tick.
On large servers this log spam causes extreme disk I/O and has already led to LevelDB corruption for multiple operators, including myself.
Defining:
"attack_interval": { "range_min": 1, "range_max": 1 }"attack_interval": { "range_min": 1, "range_max": 1 }in behavior packs suppresses the issue, which strongly indicates this is a Bedrock engine regression and not addon or server misconfiguration.
— Dgtyhy
Hi @ika, this is @Dgtyhy.
I’ve been doing extended testing on this issue and I can now confirm that this is not caused by addons, plugins, or world corruption, but by a core Bedrock engine regression introduced in 1.21.130.
The change that modified
minecraft:behavior.nearest_attackable_target.attack_intervalto requirerange_min/range_maxappears to have unintentionally broken the fallback logic used by vanilla mobs that never definedattack_intervalat all (e.g. zombies, skeletons, creepers).As a result, these mobs now continuously emit the log:
“For entity X,
attack_intervalis disabled (max <= 0); goal will fall back toscan_interval(ticks).”This log is produced every tick per affected mob, which at scale causes extreme disk I/O pressure on Bedrock Dedicated Server, leading to LevelDB compaction failures and eventual database corruption.
Explicitly defining:
in behavior packs prevents the issue entirely, which strongly indicates that the fallback logic itself was broken in 1.21.130 rather than the data definitions.
This is therefore a Bedrock engine bug and not a server/operator configuration problem.
Thanks for continuing to investigate this — this regression is currently impacting large production BDS servers.
— Dgtyhy