Check what happens when the same request arrives twice.

Fictional example: request S-17 should create one task. Use its request identifier to recognise that operation. Different requests from the same person are not necessarily duplicates.

Agree on what happens if S-17 arrives again with a different quantity. It might be a correction or a conflict; do not discard the change solely because the identifier matches.

MDN defines idempotency through the intended effect staying the same when an identical request is repeated, and notes that POST does not guarantee it. A retry button or HTTP method alone does not resolve duplication across a workflow.

For this example, request that a recognised repetition returns access to the existing task. Implementation must also handle simultaneous inputs; a manual check followed by creation does not establish that behaviour.

First, submit S-17 twice and check that only one task exists. Second, simulate task creation followed by a lost response; retrying should locate the earlier result.

Third, deliver two copies simultaneously with the technical team’s help. Check the actual task count, not just success messages. Record what the workflow returns to the sender of the second copy.

Keep the relationship between input identifier and result, plus the status needed by the operator. Define how differing data under one identifier is handled and when a person intervenes.

If your tool cannot demonstrate safe repetition, limit automatic retries and leave a review procedure. Include these cases whenever the workflow or its destination changes.