# How we provide reliability

The biggest issue with trade plugins is dupe bugs

We understood this difficulty and I started working on the plugin keeping in mind that\
it should've been designed to have as little as possible ways to produce instabilities

### We adopted 2 measures to counteract dupes:

1. Trade is divided into 4 statuses/phases: <mark style="color:red;">**REFUSED**</mark>, <mark style="color:green;">**CONFIRMED**</mark>, <mark style="color:blue;">**COMPLETED**</mark> and <mark style="color:$info;">**RETRIEVED**</mark>\
   Those 4 phases lock the player and the trade items to prevent duping by clicking, double-clicking, drag-clicking, and all the things
2. I'm using a plugin to test ZelTrade under stress conditions and on particular cases. The code of **TradeIntegrity** will be open source and released soon, so you can download it and test ZelTrade by yourself

#### ZelTrade is robust, efficiently managing disruptions to the Redis cache connection. It can also withstand server crashes, utilizing a query system to monitor all active trades within the network.

## Our testing suite

<div data-full-width="true"><figure><img src="https://2658899963-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FulSBFCQTszosGNaaOSrD%2Fuploads%2Fgit-blob-a64fd028ddda4635064b13a55364bb8b8d3e02df%2Fezgif-5-240516aede.gif?alt=media" alt="" width="563"><figcaption><p>My testing suite</p></figcaption></figure></div>

* I start with a **testing modpack** to thoroughly test each GUI feature, identifying any bugs related to item desynchronization
* The second tool is a stress test command that makes the server lag randomly
* When I test, I choose MySQL and Redis servers with **latency greater than 200ms** to amplify desynchronization issues
* Additionally i attach a debugger to the server instance to check if there is any leftover inside hashmaps and to check if there is any possible memory leak