RSpec and Database Transactions: Retry Logic Interoperability

Short Answer

No, there is no guarantee of a clean slate between retries. With transactional fixtures, RSpec opens one transaction per example and rolls it back only after the example fully finishes—including all retry attempts. An around(:each) hook wraps the entire example lifecycle, so a retry triggered inside the example (by rspec-retry or by application-level retry code) runs within the still-open outer transaction. Writes from attempt one are visible to attempt two.

What Is Confirmed vs. Likely

Confirmed, well-established behavior: use_transactional_fixtures = true (Rails) wraps each example in a transaction rolled back at teardown. Nested ActiveRecord::Base.transaction calls inside the code under test become savepoints, not real commits. An exception that rolls back to a savepoint re-raises, so an inline retry loop re-executes the block inside the same outer transaction.

Likely explanation for your uniqueness violations: the retried code inserted a row before failing. The savepoint rollback only undoes work after the savepoint; anything written before it (or in a code path without a savepoint) persists in the outer transaction. Attempt two then collides with attempt one's row.

Two Distinct Retry Cases

1. rspec-retry (example-level retry)

rspec-retry re-runs the example, and the around(:each) transactional hook does exit and roll back between attempts—each retry is a fresh example execution. If you see duplicates here, the usual cause is code that escaped the test transaction: a separate database connection, a thread touching the DB, or requires_new: true combined with explicit connection handling. Those writes commit for real and survive the rollback.

2. Application-level retry (retry_on, rescue/retry loops)

These retry inline, inside the single test transaction. Attempt two sees attempt one's uncommitted writes. Rails' retry_on re-enqueues the job rather than retrying inline, but under transactional tests the re-run still sees the fixture transaction's state, so first-attempt writes can surface as uniqueness errors.

Fixing Non-Transactional Stores and True Concurrency Retries

For non-transactional stores (Redis, MongoDB, external APIs) there is no automatic rollback at all. Reset them explicitly per attempt:

RSpec.configure do |config|
  config.before(:each) { Redis.current.flushdb }
end

For deadlock/serialization retry loops on PostgreSQL, transactional fixtures cannot faithfully exercise the path—those errors require real concurrent transactions. Opt that spec out:

describe 'deadlock retry', :no_transaction do
  self.use_transactional_tests = false
  # DatabaseCleaner.strategy = :truncation for this file
end

Verification Steps

1. Put a counter or log line inside the retried block to confirm how many times it actually executes.
2. In the spec, run a raw SQL SELECT COUNT(*) at the start of attempt two to see whether attempt one's rows are visible.
3. Check rails_helper.rb for use_transactional_fixtures and your DatabaseCleaner strategy.
4. Grep the code under test for establish_connection, thread creation, or requires_new—the classic transaction-escape hazards.

Exact config names and retry_on semantics vary by Rails/RSpec version; verify against your installed versions.