When a retry should not become a second purchase

A lost connection can leave a player unsure whether an action completed. Did the game receive the request, or should it be sent again? For actions that spend credits or move items, that uncertainty matters.

One of our development checks resends the same recorded request and compares the result with the original. The question is specific: can one intended purchase accidentally become two charges or two items? A new, deliberate purchase is a separate action; retrying the original request should not invent one.

In an isolated test of the parts shop, a test account bought one mobile tool for 1,200 game credits. The first request reduced stock by one and added one inventory item. Replaying that same request returned the original recorded outcome, with no second purchase effect. The checks also covered reopening the client at desktop and mobile sizes and inspecting the saved result.

That is a useful development result, but it is not the whole release test. A local test does not show that every service, regional connection or production restart behaves correctly. Those paths need their own checks against the actual running environment.

The player-facing aim is straightforward: when a connection is uncertain, the game should be able to distinguish a retry from a new action and preserve the outcome already earned or paid for. We are checking the recorded action and its effects together, rather than relying only on a success message.

This example uses isolated development accounts and test data. It is not an announcement that the tested shop, LA/Watts or a new recovery feature has been deployed. For the current playable experience, use the live game and the existing beta guidance. Reproducible problems can be reported through the community links already provided on this site.