Bug Reporting for Games With Player Trading Systems

Trading lets two players swap items and currency directly, and it sits on top of one of the strictest correctness requirements in your game, the trade must be atomic. Either both sides get exactly what was agreed, or neither does. When that guarantee slips, you get the bugs every developer dreads, an item that ends up in both inventories or in neither. These are not cosmetic, they corrupt your economy and reward exploiters. The hard part is that a trade bug is inherently a two-player event, and a single player's report only ever tells half the story. This post is about capturing the whole transaction so trade bugs become reproducible.

Why one player's report is never enough

When a player reports that a trade went wrong, they describe it from inside their own client. I gave them the sword and got nothing back. That account might be true, or the other player might have a mirror-image complaint, or both items might have actually transferred and one player simply did not see the inventory update because of a UI desync. From one side you genuinely cannot tell which of these happened, and acting on a partial report risks either ignoring a real dupe or refunding an item that was never lost.

A trade is a single transaction with two participants, so the unit of debugging is the transaction, not the player. The report needs to carry enough to identify the trade and then reconstruct what each side offered and what each side ended up with. Once you have both halves, the ambiguity collapses. You can see plainly whether the item count went up, went down, or stayed conserved across the two inventories, which is the only thing that distinguishes a dupe from a loss from a false alarm.

Capture the trade id and manifest

Every trade should have a server-side transaction id, and that id is the anchor for the entire report. With it you can find the server's record of the swap, both participants, the timestamps of each confirmation, and the final outcome. Capture it at report time along with the player's role in the trade, whether they were the initiator or the recipient, because the order of confirmation often matters for the bug.

Alongside the id, capture the manifest, the exact list of items and currency this player offered and the exact list they received, with item ids, stack counts, and any item instance identifiers for unique gear. Currency belongs here too, because many trade exploits hide in the currency leg rather than the item leg. The manifest from one side plus the trade id lets you pull the matching manifest from the other side out of your logs, and the two together give you the complete before and after of the swap.

Hunting duplication and conservation bugs

Item duplication is the single most damaging trading bug because a dupe can flood your economy faster than you can patch it. The signature of a dupe is a conservation failure, the total count of an item across both players after the trade is higher than before. To detect it you need both manifests and ideally a before snapshot of each inventory. If you only capture the complaining player's view, a dupe that benefits the other player is completely invisible to you.

Capturing both sides turns dupe hunting into arithmetic. You sum what each player held before and after, and if the books do not balance, you have a confirmed dupe and the trade id that produced it. The same approach catches the opposite failure, item loss, where an item leaves one inventory and never arrives in the other, usually a non-atomic swap that committed one leg and rolled back the other. Both failures are about conservation across the transaction, and both are only visible when you capture the whole transaction rather than one participant's slice of it.

Timing, confirmation, and exploit windows

Many trade bugs are timing bugs. A player swaps an item out of the trade window at the last instant after the other side has confirmed, or two confirmations race, or a disconnect lands in the middle of the commit. To debug these you need the sequence of events, when each side added items, when each side locked in, when each confirmed, and when the server committed. A timeline of these events tied to the trade id is what reveals an exploit window where the contents changed after a confirmation that should have frozen them.

Capture the confirmation state and a short event log on each side at report time, including any last-moment changes to the offer. Disconnects deserve special attention, so record whether either party dropped during the trade and at what stage. Exploiters probe exactly these windows deliberately, so a report that includes the timing of each step lets you tell an honest desync from a crafted exploit, and it gives you the precise gap in your atomicity guarantee to close.

Setting it up with Bugnet

With Bugnet, the in-game report button captures custom fields automatically, so you attach the trade id, the player's role, their offered and received manifest, the confirmation state, and a short event timeline to every trade-related report. The player taps report after a bad trade, and the report already carries their half of the transaction in structured form, ready to be matched against the other half in your logs. If a trade triggers a crash mid-commit, Bugnet captures the stack trace alongside that same transaction context, so you can see exactly where the swap died.

Because Bugnet folds duplicate reports into one grouped issue with an occurrence count, a dupe exploit that many players are quietly abusing shows up as a spiking count on a single grouped issue rather than scattered noise, which is often your earliest warning before the economy data shifts. Filter the dashboard by your trade-related custom fields to isolate reports involving a specific item or currency, and sort by occurrence to find the trade paths under active exploitation. One dashboard gives you both the individual transaction and the pattern across all of them.

Protecting the economy long term

Trade integrity is not a feature you finish, it is a property you defend continuously, because every new item, currency, or trade path is a new place for the atomic guarantee to leak. Make the trade id and both-sides manifest a standard part of every trading report so that when something looks wrong, your first move is arithmetic rather than interrogation. The faster you can prove conservation held or failed, the faster you can decide whether to roll back, hotfix, or reassure a confused player.

Watch occurrence counts on trade issues the way you would watch a fraud dashboard, because a dupe that doubles every hour is an emergency and a one-off desync is not. With both sides of every transaction captured, you can tell them apart instantly, act on the dangerous one, and close the partial-failure and timing windows that let it happen. A trading economy players trust is built on transactions you can fully reconstruct, and that starts with capturing both sides of every trade.

A trade bug is a transaction, not a story. Capture both sides and the trade id, and dupe hunting becomes arithmetic instead of guesswork.