Distinguish another attempt from another intended action.

Start with the business effect. Creating a report, appending an observation, and replacing an existing value have different consequences if repeated. An identical-looking payload does not necessarily establish that two submissions represent the same intended action.

The workflow should identify when an operation begins and what makes a later attempt part of it. That definition is needed before choosing a technical method for recognizing repeats.

If an interrupted attempt is retried as the same operation, the client and receiving service need a compatible interpretation of its identity. Creating a new identity for every network attempt can prevent the service from recognizing the relationship.

The experiment should also consider what happens after the content changes. A retry of the original operation and a new intended update may require different handling. Document the decision instead of relying on a general “deduplication” label.

Preventing a duplicate remote effect does not automatically make the interface understandable. The application may still need to show that the original operation was accepted or that its result is being checked. A user should not be left to infer success from an item disappearing.

A deliberate new action must remain possible when the workflow allows it. A repeat-handling rule should not quietly discard valid observations merely because their content resembles earlier information.

Use an interrupted response, an immediate retry, a later retry, and a genuinely new submission with similar content. Compare the remote effects and the messages shown on the device. Include a changed payload under the same proposed identity if the service supports that scenario.

The research output should explain the tested boundary and remaining dependencies. Repeat handling is a property of the whole exchange, not a promise established by disabling a button after the first tap.