with-transaction full-body retry vs with-retry commit-only retry for duplicate writes

Goal is to prevent duplicate writes when Racket transactions retry after a conflict while using the documented transaction library.

The library documents with-transaction as automatically retrying the entire body on conflict, which implies re-execution of any code in the body. with-retry is presented as an alternative that retries only the commit phase, reducing re-execution of the body. transaction-commit and transaction-rollback provide explicit control over commit points.

The constraint is non-idempotent side effects that must not repeat across retries. Documentation is unclear on whether writes performed before an explicit transaction-commit are automatically rolled back on retry, and on the exact boundaries of what with-retry re-executes under Racket 8.9+ assumptions.

Is with-retry guaranteed to avoid re-executing body code that performs non-idempotent I/O? Does transaction-commit provide a documented commit guard that isolates writes from retry? What is the documented behavior for side effects performed before an explicit commit when a conflict triggers retry?