Preventing duplicate writes during Ballerina client retries

Handling Idempotency in Network Retries

Ballerina provides built-in retry mechanisms for service clients to manage transient failures. However, when performing non-idempotent operations—such as POST requests to a database or external API—automatic retries can lead to duplicate resource creation if the initial request was processed but the response was lost.

While custom headers can be used to pass idempotency keys to downstream services, the language does not currently provide a native primitive to automatically generate and track a unique token across all attempts of a single retry loop.

What is the recommended pattern for managing idempotency keys within a Ballerina retry block to ensure a consistent identifier is used across all attempts without manually wrapping every client call in a custom state-tracking object?