PureScript Aff and External API Idempotency Integration

Managing Side Effects in Retry Logic

When implementing retry mechanisms within the Aff monad for external API integrations, ensuring that network failures do not result in duplicate writes is a critical design requirement. While PureScript provides the necessary primitives for asynchronous delays and recursive loops to handle exponential backoff, the coordination between the effect system and the remote service's idempotency requirements remains a manual implementation detail.

Integration Constraints

The primary challenge lies in maintaining a consistent request identifier across multiple attempts of a failed Aff action. If the retry logic is wrapped in a higher-order function, the state of the idempotency key must be preserved without introducing mutable state that violates the functional paradigm.

• Ensuring the same unique identifier is passed to the API across all retries.
• Preventing memory leaks during recursive retry loops in asynchronous contexts.
• Standardizing the handling of jitter and backoff intervals.

What is the most type-safe pattern for injecting idempotency keys into a recursive Aff retry loop? How can this be structured to ensure that the key is generated once per logical request rather than once per attempt?