Ballerina connector retry policy and duplicate writes on non-idempotent operations

Ballerina HTTP client and other connector clients support a retry attribute and a configurable retry policy with back-off and max attempts.

The retry mechanism reissues the same request on transient failure. For non-idempotent write operations this raises uncertainty about duplicate execution, as the runtime does not automatically add idempotency keys or coordinate with transaction boundaries. The transaction keyword exists for database operations, but there is no documented integration between retry policy and transaction scope to prevent duplicate writes.

Documentation does not specify a standard pattern for combining retry with idempotency keys or compensating actions for non-idempotent operations.

Does Ballerina define a supported way to bind an idempotency key to a connector request that is subject to retry? Is there guidance on scoping retry away from non-idempotent writes when idempotency cannot be guaranteed? What is the current design stance on providing a higher-level abstraction for deduplication on retry?