Server crash / watchdog timeout triggered by NetworkToolItem.regenerateCablePositions on large cable networks

[LSK-LW]

Bug Report: Server crash / watchdog timeout triggered by NetworkToolItem.regenerateCablePositions

Summary

Toggling the Network Tool overlay on a large cable network causes the server main thread to hang indefinitely, ultimately triggering the ServerHangWatchdog and crashing the server.

Environment

Field	Value
Minecraft	1.21.1
NeoForge	21.1.221
SFM	4.32.0
Java	(server default)

Steps to Reproduce

1. Build a large SFM cable network (exact size unknown, but large enough that regenerateCablePositions takes significant time).
2. Hold a Network Tool and toggle the overlay (packet: ServerboundNetworkToolToggleOverlayPacket).
3. The server main thread blocks inside LongOpenHashSet.addAll / LongOpenHashSet.add.
4. After 60 seconds, the ServerHangWatchdog fires and the server crashes.

Expected Behavior

regenerateCablePositions should either complete in bounded time or be offloaded to an async/background thread so it does not stall the main server tick.

Actual Behavior

The server hangs on a single tick and is killed by the watchdog:

java.lang.Error: ServerHangWatchdog detected that a single server tick took 60000700.00 seconds (should be max 0.05)
    at it.unimi.dsi.fastutil.longs.LongOpenHashSet.add(LongOpenHashSet.java:402)
    at it.unimi.dsi.fastutil.longs.AbstractLongCollection.addAll(AbstractLongCollection.java:169)
    at it.unimi.dsi.fastutil.longs.LongOpenHashSet.addAll(LongOpenHashSet.java:378)
    at ca.teamdman.sfm.common.item.NetworkToolItem.regenerateCablePositions(NetworkToolItem.java:188)
    at ca.teamdman.sfm.common.net.ServerboundNetworkToolToggleOverlayPacket$Daddy.handle(ServerboundNetworkToolToggleOverlayPacket.java:42)

Crash Report UUID

9812f2a0-2d61-448f-be53-5ecf9a9c0979

Full Crash Log

crash-2026-04-21_10.49.48-server.txt

Suggested Fix

regenerateCablePositions appears to perform an unbounded traversal of the cable graph on the main thread. Possible mitigations:

• Run the traversal asynchronously and send the result back to the client.
• Add a depth/count limit with a warning when the limit is exceeded.
• Cache cable positions incrementally on cable placement/removal rather than recomputing on demand.

Additional Notes

• The crash is 100% reproducible by toggling the overlay on the affected network.
• No other mod appears to be involved; the stack trace originates entirely within SFM.
• Removing or breaking up the large cable network is the only current workaround.

[TeamDman]

Thank you for the report!

Here is the relevant source code

SuperFactoryManager/platform/minecraft/src/main/java/ca/teamdman/sfm/common/item/NetworkToolItem.java

Lines 168 to 191 in ace3cf5

	public static void regenerateCablePositions(
	ItemStack pStack,
	Level pLevel,
	Player pPlayer
	) {
	// Initialize with default capacity
	// We don't know how many *unique* positions we are going to see
	BlockPosSet cablePositions = new BlockPosSet();
	BlockPosSet capabilityProviderPositions = new BlockPosSet();
	// Find the networks and track the positions
	for (CableNetwork cableNetwork : (Iterable<CableNetwork>) getNetworksForOverlay(
	pStack,
	pLevel,
	pPlayer
	)::iterator) {
	cablePositions.addAll(cableNetwork.getCablePositionsRaw());
	capabilityProviderPositions.addAll(cableNetwork.getCapabilityProviderPositionsRaw());
	}
	// Update the item data
	setCablePositions(pStack, cablePositions);
	setCapabilityProviderPositions(pStack, capabilityProviderPositions);
	}

The network tool does have alternate modes for disabling the overlay, but that happens after the lagging function has already been called to send the information to the client.

Right now the network tool stores a copy of the positions of blocks that are members of networks by receiving a copy of that information from the server.
When the server is building that information, it is deduplicating the block positions.
This is incurring extra overhead.

A small fix is to add a safety behaviour to the network tool and label gun to only distribute a small amount of information to the player, omitting some information.

Omitting information when doing label operations like contiguous assignment and disassignment could desync if done by a client with incomplete information.

Having the server perform the mutation means that the client could send a change with an estimated changed block count of 10 and the server perform a change that would affect hundreds.

Disabling contiguous modifications on large networks is less preferrable than having to implement the label change confirmation GUI flow in a way where the server finalizes the plan and then confirms it with the client before proceeding instead of the client submitting the finalized plan.