[gabsow]

dumpAndReload() fails if its synchronous SAVE overlaps an active BGSAVE. Retry only the exact “Background save already in progress” response, with a ten-second deadline per connection. Other errors and an exhausted retry deadline still fail the test. Both primary and replica connections retain their own successful SAVE before DEBUG RELOAD NOSAVE, so waiting for an older background snapshot cannot lose subsequent writes.

Validation: reproduced the original failure against Redis with a deliberately slowed BGSAVE. With this change, save/reload completes and a key written after the background snapshot started survives reload. The StandardEnv unit suite passes (44 passed, 4 skipped), including retry ordering, replica handling, deadline failure, and immediate propagation of other errors. Existing test warnings remain. Downstream adoption and nightly verification are still required.

---

Note

Low Risk
Test-harness-only change to save/reload timing; no production Redis server logic, with bounded retries and unchanged failure behavior for other errors.

Overview
dumpAndReload() no longer fails when a synchronous SAVE races an in-flight BGSAVE. For each master (and replica, if enabled) connection, it retries SAVE only on the exact Redis error Background save already in progress, with a 10s deadline and short sleeps between attempts; any other error or an expired deadline still aborts before DEBUG RELOAD NOSAVE.

Unit tests mock StandardEnv to cover successful retry on both roles, no reload after timeout, and immediate failure for unrelated save errors.

^{Reviewed by Cursor Bugbot for commit 913fad0. Bugbot is set up for automated code reviews on this repo. Configure here.}