Reflex @retry decorator and non-idempotent write operations

Event Handler Retry Behavior

The @retry decorator in reflex.utils.retry allows event handlers and background tasks to automatically re-execute upon encountering an exception. While this ensures resilience against transient failures, the decorator operates independently of the function's side effects.

Idempotency Constraints

When applying this decorator to operations that perform database writes or external API calls, there is a risk of duplicating records if the failure occurs after the write is committed but before the function returns successfully. The current implementation does not provide a built-in mechanism to track the state of completed writes across retry attempts.

For applications using the stable release of Reflex, it is unclear how to best integrate idempotency guards within the @retry workflow without manually wrapping every single write operation in a conditional check.

• Does the @retry decorator support any internal state tracking to prevent duplicate execution of specific code blocks?
• What is the recommended pattern for ensuring write safety when using the default exponential backoff configuration?