fix(restore): return from a failed restore without waiting for its cleanup

A failed or canceled native restore cleared its ongoing marker under a
fresh one-minute deadline, while the restore itself could still hold the
object lock that the cleanup waits for. The request then stalled for
about a minute (60 s in TestNativeRestoreWithoutOuterLock and
TestRestoreRecoversStrandedMarker).

Try the cleanup for 100 ms and leave the rest to the bounded background
retries, which already exist for the pools path and now also serve the
single-set path. Each retry still takes the object lock afresh and clears
only the marker of its own attempt. The CI restore race step drops from
about 260 s to 37 s.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Feng Ruohang <rh@vonng.com>
This commit is contained in:
Feng Ruohang
2026-11-09 22:07:59 +08:00
parent 0a238589a4
commit 86dc6ee2e2
5 changed files with 66 additions and 15 deletions
+6
View File
@@ -263,7 +263,13 @@ func TestNativeRestoreWithoutOuterLock(t *testing.T) {
before := nativeRestoreSnapshot(t, r)
ctx, cancel := context.WithTimeout(t.Context(), 200*time.Millisecond)
defer cancel()
start := time.Now()
err = er.RestoreTransitionedObject(ctx, r.bucket, r.object, nativeRestoreOptions(r, oi.VersionID))
// Failure cleanup must return while this caller still holds the
// object lock, leaving marker recovery to the background retry.
if elapsed := time.Since(start); elapsed > 5*time.Second {
t.Errorf("restore blocked on failure cleanup for %s", elapsed)
}
if err == nil {
t.Error("restore wrote through another caller's lock")
}