Reflex @retry decorator and non-idempotent write operations

Direct Answers

No, the @retry decorator does not track internal state to prevent duplicate execution of specific code blocks. It re-invokes the entire wrapped function from the beginning on each exception. If a database write commits but a later statement (or the return path) raises, the retry runs the write again — producing duplicate rows or repeated external API calls.

The recommended pattern for write safety under exponential backoff is an idempotency key enforced by a unique constraint at the storage layer. Generate one stable key per logical operation (e.g., per form submission), persist it alongside the write, and let the database reject duplicates via INSERT ... ON CONFLICT or an upsert. Backoff timing does not affect this risk.

Why the Decorator Cannot Help

A generic retry wrapper has no visibility into which statements inside the function succeeded. It only sees an exception and restarts the call. This is by design: the decorator is meant for transient failures in the call (network blip, deadlock, temporary unavailability), not for compensating side effects that already occurred.

Safe Patterns for Non-Idempotent Writes

Database Writes (Recommended)

1. Generate an idempotency key before the retried handler runs (e.g., in the frontend or a thin wrapper) and pass it as an argument.
2. Add a unique column idempotency_key to the target table.
3. Inside the handler, use an upsert:

   await session.execute(
       insert(MyModel).values(
           idempotency_key=key,
           payload=data
       ).on_conflict_do_nothing(index_elements=['idempotency_key'])
   )
   await session.commit()

4. Retries become harmless — the second attempt finds the key and does nothing.

External API Calls

• If the provider accepts an idempotency key (Stripe, SendGrid, many others), pass the same key on every retry.
• If not, record the key and the provider's response in your own table with a unique constraint before calling. On retry, check the table first and return the stored response.

Alternative: Gate the Side Effect

Move the write out of the retried function. Let the retried section only perform the failure-prone call (e.g., a flaky HTTP request). Persist a status flag (pending/done) before attempting the write, then complete the write only if the flag is still pending. This still requires a unique constraint or atomic compare-and-swap to avoid races.

Verification Steps (Run Locally)

1. Inspect the installed utility:

   python -c "import reflex.utils.retry; import inspect; print(inspect.getsource(reflex.utils.retry.retry))"

2. Write a test handler that inserts a row then raises on first call; confirm whether a second row appears after retry.
3. Add the unique constraint and re-run — duplicates should be prevented.

Assumptions & Uncertainty

• The module path reflex.utils.retry and decorator signature are version-sensitive; the above reflects typical retry-decorator behavior but was not confirmed against a specific Reflex release.
• Check-then-write in application code without a database unique constraint has a race condition — two concurrent attempts can both pass the check.
• Client-generated idempotency keys must be stable across retries of the same logical operation but unique across distinct operations; regenerating the key inside the handler defeats the guard.
• Background tasks that outlive the request need the idempotency record stored durably, not in in-memory state.

One Diagnostic Detail Needed

Which Reflex version are you running, and does your handler execute inside a request-scoped transaction or a background task? The answer changes whether the idempotency key must survive process restarts.