Crash Reporting for FishNet Unity Games

FishNet gives indie Unity teams a fast, free networking stack with serious client side prediction built in, and that prediction is exactly where the hardest crashes hide. When the client predicts movement and the server reconciles it, your code runs the same logic twice under different conditions: once optimistically on the client and again authoritatively on the server. Under real latency these diverge, and a crash that never appears in editor testing surfaces the moment a reconcile pass corrects a predicted state your code assumed was final. This post covers what crashes FishNet games and how to capture the prediction and ownership context that makes each one reproducible.

Prediction and reconciliation as a crash surface

FishNet replicate and reconcile callbacks run your movement and gameplay logic repeatedly: the client replays inputs while reconciling to the latest authoritative state from the server. If your code mutates state that is supposed to be reconciled, or reads a value that the reconcile just rewound, you get an exception that depends entirely on timing and latency. In the editor with near zero ping, the reconcile barely does any work, so the bug stays hidden until a player on a real connection triggers a deep replay.

The crucial context is therefore whether the crash happened inside a replicate or reconcile pass and at which tick. A null reference during reconciliation usually means your state did not survive a rewind cleanly, while the same line crashing only during replicate points at an input replay assumption. Without the pass and tick recorded, a prediction crash looks like a random gameplay null, and you will chase it in the wrong system entirely.

Server versus client divergence

Like other Unity networking stacks, FishNet runs shared NetworkBehaviour logic on both the server and clients, and the same guards apply: IsServer, IsClient, IsOwner. The prediction layer makes the server and client split sharper, because the client deliberately runs ahead of the server and then snaps back. A crash that fires on the client but never on the server often means a predicted value escaped into code that assumed authoritative state, and capturing the role makes that distinction instant.

Capture the owning connection too. FishNet ownership drives who may predict for an object, and ownership changes mid match, for example when a player picks up a controllable object, are a classic crash trigger. A replicate running for an object whose ownership just transferred, or a reconcile applied to an object the client no longer owns, produces an exception that only makes sense once you can see the owner at crash time. Role plus owner plus pass narrows a FishNet crash from a whole subsystem to a single transition.

Spawn timing and RPC races

FishNet spawns and despawns networked objects across the connection, and like any such system it has windows where a message arrives for an object that is not ready or already gone. An ObserversRpc that targets a despawned object, a TargetRpc sent to a client mid disconnect, or a spawn message processed before dependencies initialize all produce crashes that depend on network timing rather than logic. Recording whether the object was spawned and initialized when the crash occurred separates these races from steady state bugs.

The reconcile system raises the stakes because spawn timing interacts with prediction: an object that spawns during a replay can leave your state machine in a configuration it never reaches in normal play. Capturing the spawn state alongside the tick and pass lets you see when a crash sits at the intersection of spawn timing and reconciliation, which is the single nastiest category of FishNet bug. Those are the ones worth reproducing carefully with simulated latency, because they will keep hitting players otherwise.

Reproducing under simulated latency

The reason FishNet crashes evade local testing is the absence of latency, so the reproduction strategy is to add it back deliberately. FishNet and Unity both offer latency and packet loss simulation, and once your crash reports tell you a bug fires during reconcile at a certain tick depth, you can dial in the ping that produces that depth. You are no longer guessing which of a hundred frames diverged; the captured tick and pass tell you exactly how far the client had run ahead when it broke.

Combine that with the owning connection and you can script a precise repro: connect a second client, transfer ownership at the moment the reports indicate, and apply enough latency to force a deep reconcile. This turns the most intimidating FishNet crashes, the ones that only ever appeared in player reports, into something you can step through in the editor. The captured context is what converts an unreproducible prediction desync into a bug with a clear set of conditions you can recreate on demand.

Setting it up with Bugnet

Bugnet captures FishNet crashes with their full stack trace and device context, and the in game report button snapshots the game state at the moment of failure, so you see the scene and objects involved alongside the exception. To make prediction crashes tractable, use custom fields to attach the role (server or client), the owning connection, the current tick, and whether a replicate or reconcile pass was running. Those few fields are the difference between a random null and a clearly located reconciliation bug, all collected in one dashboard.

Bugnet folds duplicate reports into a single issue with an occurrence count, which suits FishNet crashes that recur across many sessions at varying latencies. You can see that a reconcile crash hit 95 times, always on clients, always after an ownership change, and prioritize it over a rarer spawn race. Filtering by role and pass confirms whether a fix landed, and the occurrence count tells you whether a prediction bug is a long tail nuisance or a top priority affecting most of your higher ping players.

Hardening prediction over time

Make prediction context part of your standard reporting so every FishNet crash records its pass, tick, role, and owner without extra thought. The instrumentation is small and lives in your reporting wrapper, and it pays off every time a player on a bad connection hits a reconcile bug you could never see locally. Teams that skip it spend release after release rediscovering that prediction is involved, instead of reading it off the report and moving straight to the fix.

As you accumulate grouped crashes, you build a map of which of your predicted behaviours survive reconciliation cleanly and which do not. That map guides where to add deterministic state handling and where ownership transitions need guarding. The end state is a netcode layer where prediction crashes are rare and, when they do appear, arrive with the exact tick and pass that produced them, so the fix is a focused change rather than a hunt through your entire gameplay loop.

FishNet prediction crashes hide because the editor has no latency. Capture the pass, tick, and owner, then add the ping back to reproduce them on demand.