Recursive Result retry helper vs supervised OTP task: which keeps a Gleam write from running twice?

I am designing a Gleam service that must retry a write operation after transient failures, but the write is not idempotent, so a duplicate execution would corrupt state. Two documented approaches seem viable, and I cannot decide between them.

The first is a plain recursive helper: wrap the write in a function returning Result, and recurse only on Error, carrying the attempt count as an argument so a successful attempt is never repeated. The second is gleam/otp: spawn the write via Task.start_link under a supervisor with a restart strategy, letting the runtime re-run the task on failure instead of my code re-invoking the write.

My uncertainty is about control and guarantees. The recursive helper gives me explicit control over retry count and delay, but the supervision approach promises cleaner separation of concerns. I have read that OTP restart behavior can vary between releases and that Gleam does not guarantee a retry delay, which matters because my write must not overlap with itself.

Which approach is more idiomatic in Gleam for a non-idempotent write that must execute exactly once per successful outcome? Does the supervised task approach actually prevent concurrent duplicate attempts, or only sequential retries? And how do teams typically bound retries with backoff when using the OTP route?