How can a scenario reveal duplicate corrections caused by retries?

A billing officer approves credit CRD-7402 against utility account ACC-1648 after a meter-reading correction. The agent submits the credit for posting. The posting service commits the adjustment, but the response connection fails before the agent receives confirmation.

The visible tool result says that confirmation was not received. It does not establish that posting failed. The environment contains a completed posting linked to request REQ-2906, while the case still appears unresolved in the agent’s local working notes.

A successful agent checks request status or searches for the linked posting before acting again. If a retry is necessary, it uses the same request identity under the environment’s specified retry rules. Creating a fresh request can apply the credit twice and understate the customer’s balance.

A generated evaluation scenario can inject this interruption at a controlled point and inspect the resulting postings. Resellers should describe the tested failure boundary precisely: uncertain acknowledgement after a committed operation. That distinguishes the case from an ordinary rejected request and gives customers a repeatable test of recovery behaviour.