What causes the scoreboard and timer resetting after host migration?

Match score and timer are tracked only in the host's local state, so when the host leaves the new host starts fresh and every client's UI snaps back to zero.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix Host Migration Resetting the Scoreboard and Match Timer

Quick answer: Replicate authoritative match state to all clients continuously so the new host can adopt it on migration, or checkpoint state to a relay the migrating host restores from.

Host migration that drops the score, timer, or objective progress feels like the match restarted. The root cause is keeping that state only on the host rather than replicating it, so the handoff has nothing to inherit.

How to fix it

1. Replicate match state to all peers

Keep score, timer, and objective progress as replicated state visible to every client, not host-only locals. The new host then already has the current values to take ownership of.

2. Promote state ownership atomically

During migration, transfer authority over the match-state variables to the new host in one step so no client recomputes from defaults in the gap.

3. Pause the simulation during handoff

Freeze the timer and scoring while migration completes, then resume, so a few seconds of lost connectivity does not corrupt the final tally.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Ship the fix, watch the signature disappear from the next build. That's how you know it's really gone.