Jest Circus × test lifecycle hooks: can retried tests avoid duplicate external writes?

Direct answer

No. Jest’s jest.retryTimes() re‑executes the entire test function and every beforeEach/afterEach hook on each retry attempt. The framework does not expose a retry‑aware hook, an attempt counter, or a context object that lets user code distinguish a retry from the first run.

Confirmed behavior

• Full re‑run: Each retry is treated as a fresh logical invocation. beforeAll/afterAll run once per test file, but beforeEach/afterEach run before and after every attempt.
• No retry context: There is no documented API (e.g., expect.getState().attempt) and no event emitted to test code that identifies the current attempt number.
• Parallel workers: When --maxWorkers > 1, each worker runs its own retry loop independently, compounding duplicate side effects.

Why a semantic change would break existing suites

Skipping beforeEach/afterEach on retries would violate the isolation guarantees many test suites rely on: resetting mocks, clearing databases, releasing connections, or cleaning up temporary files. Making retries “hook‑less” would introduce subtle ordering bugs and is contrary to Jest’s design principle of keeping retries simple and stateless.

Minimal convention to guarantee idempotent integration writes

Since the framework cannot suppress hooks, the safety burden falls on the test author. Two practical patterns avoid per‑test boilerplate:

1. Idempotency keys via a test‑scoped wrapper – Wrap your external client (DB, queue, filesystem) in a helper that generates a unique key per logical test run (e.g., testPath + '#' + attempt). The attempt number can be captured in a custom reporter listening for the test_retry event and stored in a global map keyed by test file + test name. Use that key for upserts, deduplication headers, or transaction savepoints.
2. Transactional rollback in afterEach – Run integration tests against a database that supports transactions (PostgreSQL, MySQL, SQLite). In afterEach, issue a ROLLBACK (or use a library like @databases/pg-test that automates this). Because afterEach runs after every attempt, each retry starts from a clean state without duplicate commits.

Verification you can run today

// retry-hooks.test.js
let counter = 0;
beforeEach(() => { counter++; });

test('fails once then passes', () => {
  if (counter === 1) throw new Error('first attempt');
  expect(true).toBe(true);
});

// jest.config.js
module.exports = { testRunner: 'jest-circus' };

// Run:
# npx jest retry-hooks.test.js --runInBand --retryTimes=2

Observe that counter becomes 3 (initial + 2 retries), proving hooks re‑run on every attempt.

One missing detail that changes the recommendation

What external system are you writing to (relational DB, message queue, file system, HTTP API)? The idempotency strategy (upsert vs. deduplication header vs. transactional rollback) depends on the target’s capabilities.